一个集团有多个品牌，或者同一产品需要服务不同市场时，团队常在两种做法之间摇摆：每个品牌复制一套组件，维护很快分散；所有品牌共用同一外观，又难以表达差异。多品牌设计系统要解决的，是哪些规则可以共用、哪些差异应该被明确配置，以及一次更新如何安全影响多个使用方。
它不只是颜色合集，也不只是一套代码。组件、变量、内容规则、文档和发布流程共同决定系统能否持续使用。本文围绕“两个品牌复用同一组登录组件”展开；初次建立整体体系，可以先结合设计系统搭建步骤理解基础范围。
先确认复用什么，不要先追求统一多少
列出各品牌最常用的页面和组件，再比较结构、行为、内容与视觉。两个登录按钮的颜色不同，但加载、禁用、错误恢复逻辑相同，通常适合共享结构和行为。若一个品牌需要复杂身份验证，另一个只提供邮件链接登录，就不能因为按钮长得相似而强行共享整条流程。
把差异分为三类：可配置的视觉差异、可组合的结构差异、必须独立处理的业务差异。颜色和字体可能属于第一类；卡片有无辅助说明属于第二类；审批权限与数据处理属于第三类。边界越早明确，组件里充满品牌名称判断的情况越容易避免。
开始时选择覆盖面大、风险可控的一组组件，例如按钮、输入框和提示信息。先让两个品牌分别完成一条完整任务，再决定是否扩展到导航、复杂表格和业务模板。组件数量增长，不等于复用能力已经被验证。
把基础值、语义角色和组件映射分开
基础值层保存可选的颜色、间距、圆角和字体等，例如一组紫色或青色、统一间距阶梯。它回答“有哪些值可以使用”，不直接规定每个值承担什么任务。
语义角色层回答“这个值用来做什么”，例如主操作背景、默认正文、危险提示、弱分隔线。品牌A可以让主操作背景映射到紫色，品牌B映射到青色，但“主操作”的含义保持一致。
组件映射层把语义角色用于具体组件及其状态。登录按钮默认背景引用主操作色，错误提示引用错误文本色，聚焦轮廓引用焦点角色。不要让每个组件直接选择一份品牌色号，否则换品牌时仍要逐个检查手工覆盖。
层级并非越多越好。小团队可以先使用基础值与语义角色两层，等出现明确复用需求再增加组件层。每一层都应减少重复决策；如果团队无法解释某个中间名称的用途，就可能只是增加维护成本。
USWDS 的设计变量说明用有限的颜色、间距和排版选项支持一致性；Carbon 的主题机制则说明如何让稳定的角色对应不同主题取值。两者可帮助理解“名字与用途稳定，具体值按主题变化”的思路。
命名应该解释用途，也要允许未来变化
主操作按钮的背景不要命名为“紫色按钮”，因为另一品牌可能使用青色，未来也可能调整品牌色。可以采用表达用途的名称，再把品牌值放到映射中。命名规则需要和开发共同确定，明确分隔方式、大小写、状态后缀与弃用方式。
为每个重要变量补充用途、允许场景、负责人和不适用情况。比如“危险操作色”不能因为醒目就被用于普通促销按钮；错误语义、品牌强调和选中状态也不应只因当前颜色相似而合并成一个变量。
变量引用需要检查缺失和循环。一个角色引用另一个角色时，应能追溯到最终有效值。把不存在的名称留在文件里，可能使设计稿和实际代码出现不同回退结果。Design Tokens Community Group 的格式规范包含类型、分组和引用规则；采用具体工具时，还要验证其实际支持范围，不能假定所有工具都能完整导入同一种格式。
品牌、明暗模式和密度，是不同维度
品牌决定身份表达，明暗模式决定不同背景下的视觉关系，紧凑或舒适密度决定信息布局。把三者混为一套名为“品牌B深色紧凑版”的巨大组件库，会让组合数量快速增加。应先确定哪些维度可以独立覆盖，哪些组合需要单独设计与测试。
例如品牌切换可以更改主操作色与字体，密度切换影响控件高度和间距；但字体变化也可能改变按钮宽度，因此独立配置不意味着不需要组合验收。至少覆盖实际支持的品牌与模式组合，并使用最长文案、错误状态和较窄容器测试。
明暗模式不能简单反转颜色。背景、浮层、边框、图标和焦点需要保持各自关系；品牌色在浅底上可用，不代表在深底上同样清晰。系统应记录哪些组合已验证、哪些暂不支持，避免业务团队自行拼出未经检查的版本。
用一条完整任务检验架构
以品牌A和品牌B的登录任务为试点，先共享输入框、按钮和提示结构，再分别设置品牌字体、颜色与圆角。把空内容、格式错误、加载、登录失败和成功跳转一起画出来，不能只比较两张默认态截图。
试点时记录三种情况：直接复用、通过已有属性配置、需要新增能力。若某个品牌每次都必须脱离组件修改，先判断是组件缺少合理扩展点，还是业务本来不属于共享范围。不要把所有例外立刻写进公共组件，也不要把所有例外都推回品牌团队处理。
设计与开发一起核对：同名变量是否指向相同语义，状态属性是否一一对应，品牌覆盖是否改变了操作行为。还要检查文字长度、焦点、错误说明和缩放；共享结构出现的问题，可能会同时影响多个品牌。
试点记录不应只写“已适配两个品牌”。更有用的结论是：哪些结构稳定、哪些变量需要拆分、哪些业务分支仍由品牌独立维护。这样下一组组件接入时，团队能够复用判断依据，而不必重新争论架构。
发布治理决定系统会不会再次分叉
明确公共层与品牌层的维护责任。品牌团队提出需求时，附上任务、当前限制、影响范围和不能用现有配置解决的原因。维护者据此判断新增公共能力、增加品牌覆盖，还是保留本地实现；不要只凭哪个团队声音更大决定组件演进。
每次发布说明变化类型：值的调整、结构变化、行为变化或名称弃用。即使只调整基础间距，也可能影响多个组件的布局，需要评估覆盖范围。对不兼容变更提供迁移说明、替代名称和过渡安排，保留可恢复的上一版本。
先在试点页面验证，再逐步扩大使用范围。业务团队应该知道自己依赖哪个版本、哪些更新必须跟进、哪些可以延后。设计库与代码库如果分别更新，需要有明确的对应关系，不能让同一个组件名称在两处代表不同状态。
用例外清单判断架构是否需要调整
定期查看品牌团队的本地覆盖，而不只统计公共组件的数量。如果多个品牌反复以相似方式修改同一组件，可能说明共享层缺少合理能力；如果只有单一业务需要特殊行为，则可能应该保留独立组件。例外是否值得纳入公共层，应根据需求重复程度、维护责任和测试成本判断。
被替代的旧变量和组件应有可查的迁移记录。直接删除看似没人使用的名称，可能破坏尚未升级的页面。先确认使用方、提供替代方式并安排兼容期，再完成清理，才能让系统迭代与各品牌的发布节奏相互配合。
多品牌组件的验收清单
- 每个共享组件有清楚用途，品牌差异通过约定接口表达。
- 语义名称在各品牌含义一致，不把错误色、强调色和选中色混用。
- 变量引用有效，缺失值有明确处理，不存在循环引用。
- 实际支持的品牌与模式组合都经过检查，包括长文案和异常状态。
- 设计与实现的结构、状态和版本能够对应。
- 新增需求、弃用迁移、发布与回退都有责任人和记录。
在Pixso中整理共享组件和不同品牌的状态画面，可以帮助团队在同一处比较差异。先从一组能稳定复用的组件开始，配合组件库建设方法逐步扩展，让品牌表达与协作规则一起成熟。
