设计系统里两个按钮看起来几乎一样时，应先比较它们的语义、行为、状态和使用条件，再决定是否合并。视觉接近不代表可以共用；若它们承担相同操作却只是历史样式不同，可以统一，若作用和后果不同，则应保留清楚的区别。
从操作意义开始，而非先比颜色
收集两个按钮的实际使用页面，记录点击后做什么、对数据或任务有什么影响，以及用户需要知道什么。开始查询、保存草稿和最终提交，即使尺寸相同，也可能需要不同反馈和判断条件。
同时记录名称和说明。某个按钮被不同团队叫成不同名字，不一定代表多个组件；反过来，同样叫“确认”的按钮，也可能分别表示关闭提示与不可逆地提交结果。组件身份需要业务语义支持。相关操作可参阅《B端组件库怎么规划？先做高频组件还是一次性做全套》。
成功标志是团队能说清这两个按钮的共同规则与差异，不再只以截图看起来相近作为合并理由。
建立四项比较清单
比较语义、点击行为、状态和使用环境。状态包括可用、禁用、加载和错误等实际存在的条件；使用环境包括密集工具区、主要任务末尾或特殊设备，不必为了清单完整虚构所有场景。
把差异分为有业务理由的差异和没有明确理由的差异。前者可能需要组件变体或独立规则，后者则可以进一步核对是否来自旧版本、手工样式或交接遗漏。决定需要记录理由与确认人。
与界达设计工作室（JVDS）沟通UI/UX规范时，可把实际使用样本和比较清单作为输入。设计系统、组件代码及治理支持的具体交付范围按项目确认，不默认一份视觉规范包含全部实现。
合并后要验证表达能力
若决定合并，先确认共享组件能够表达现有的必要状态与行为。只合并图层名称，却让每个页面继续单独修改规则，容易产生隐藏分歧；过多没有说明的开关，也可能让使用者无法判断怎样选择。
假设两处“保存”都保留草稿，但一处另有确认条件，应检查这是可解释的状态差异，还是需要独立任务流程。组件合并不能偷偷改变业务步骤，也不能为了复用删掉必要提示。
在代表页面试用合并方案，检查文字长度、反馈、禁用原因和布局。成功标志是原任务仍能完成，使用者与开发人员都能说明该选哪种配置，不需要记住某个历史页面的特殊写法。
保留差异也要写明选择规则
如果两个按钮确实不能合并，为它们写不同的适用条件和例子，说明何时选用以及不适用的场景。名称应能帮助判断，避免简单叫“按钮一”“按钮二”或用创建日期充当身份。
记录当前页面如何迁移或保留，不必一次重做所有界面。对影响较大的变动，先确认行为兼容和实施资源；设计文件与代码采用不同状态时，需要说明，不能宣布系统已经全部统一。
成功标志是后续人员面对相同问题能根据规则做决定，而不是再复制一个新按钮。设计系统的价值来自可解释的选择与持续维护，组件数量减少只是可能的结果，不能单独作为成功标准。相关操作可参阅《设计系统会不会限制创意？真正的问题不是组件太统一，而是系统设计得太死》。
常见问题
按钮颜色不同，就一定要分成两个组件吗？
不一定。若语义和行为相同，颜色差异可以按真实用途讨论变体；若颜色承担重要任务区别，就应保留说明。组件划分应同时看状态和使用条件，不能只按视觉判断。
两个组件已经被很多页面使用，是否不适合合并？
使用范围大意味着需要更清楚的影响检查，不代表不能合并。应先确认必要规则与迁移对象，选择代表页面试用；若当前资源不足，也可以先规范选择并记录后续合并条件。
链接复制成功
