只要一个团队开始同时服务多个品牌，就几乎一定会遇到同一个问题：
- 所有品牌都想保留自己的视觉特征
- 但团队又不想维护好几套完全独立的组件体系
这就是多品牌设计系统要解决的核心矛盾。它不是简单地“换颜色换 Logo”，而是要在统一平台能力和品牌差异之间找到可长期维护的平衡点。
多品牌不是多复制几套主题文件
很多团队第一次做多品牌，会自然选择最直接的方式：
- 品牌 A 一套变量
- 品牌 B 再复制一套变量
- 品牌 C 继续复制
这种方法短期能跑，但品牌一多，很快就会失控：
- 相同组件被维护出多个分支
- 共性能力改一次要同步好几处
- 谁是平台能力、谁是品牌差异越来越说不清
多品牌设计系统真正需要的是分层，而不是复制。
更稳的结构是“基础层 + 品牌层 + 场景层”
一个更容易长期维护的架构通常分成三层：
- 基础层：间距、排版、交互状态、组件 API 这些跨品牌共用能力
- 品牌层：颜色、字体、圆角、阴影、品牌语气等可变资产
- 场景层：营销页、后台、会员中心等具体业务落地规则
这样做的意义在于：品牌变化不会轻易冲击组件结构，而基础升级也不必把每个品牌都重做一遍。
Token 体系决定多品牌扩展效率
多品牌设计系统里，最容易被低估的不是组件，而是 token 命名。
如果 token 直接写成：
blue-500brand-redbutton-green
后面品牌一多，就会越来越难抽象。
更稳的方式是先定义角色，再映射品牌：
color-action-primarycolor-surface-brandcolor-text-emphasis
这样品牌只是在映射层变化，而不是把组件语义改掉。
组件层要控制“品牌可变范围”
并不是每个组件都应该开放同样程度的品牌自由度。
例如：
- Button、Badge、Banner 这类品牌感强的组件，可以放宽外观差异
- Table、Form、Drawer 这类结构性组件，更应该保持交互和信息结构稳定
如果所有组件都被允许深度品牌化，最后多品牌系统往往会退化成“同名不同物”。
失败案例：三个品牌共用一个组件库，但每次发布都要人工逐品牌验收
这是多品牌系统很常见的隐性失败：
- 表面上是一个共享组件库
- 实际上每个品牌都有一堆例外规则
- 每次升级都要人工逐品牌检查视觉和交互
问题不在“品牌太多”，而在没有定义清楚哪些能力应该共用，哪些差异应该被限制。
一旦品牌差异没有边界，所谓共享就会慢慢失效。
多品牌系统一定要把升级策略一起设计
真正的难点不在接入第一个品牌，而在第六个月之后：
- 新品牌接入时，能否复用已有 token 结构
- 共享组件升级后，旧品牌是否还能平滑跟进
- 视觉规范调整时，是否能准确评估影响面
多品牌设计系统要想稳定，必须同时具备：
- 可扩展的 token 层
- 可约束的组件层
- 可追踪的升级流程
一份可直接复用的检查清单
- 设计系统是否拆分出基础层、品牌层和场景层
- token 是否以角色命名，而不是直接绑死颜色值
- 组件是否明确了哪些外观可变、哪些结构不可变
- 多品牌差异是否被限制在可控范围内
- 共享组件升级时，是否能清楚识别各品牌影响面
总结
多品牌设计系统的目标，不是让每个品牌都“各做各的”，而是在统一基础能力上安全地表达差异。只要分层、token 和升级策略一起设计，它就会是平台资产，而不是多套组件库的维护陷阱。
进一步阅读：
