设计系统常见的尴尬是：Figma里有一套按钮，代码里有另一套按钮。两边都叫Button，却各自维护尺寸、状态和命名。新页面一多，设计师说“开发没还原”，开发说“设计稿每次都不一样”。
真正的一一对应不是把组件截图复制进代码，而是让设计和前端共享同一套语义与约束。
01 先统一组件的身份和边界
组件应解决一个稳定、可复用的问题。按钮、输入框、提示、表格是基础组件；“客户信息卡”更接近业务组件。边界不清时，团队会出现几十个外观相似、用途不同的组件。
建立组件清单时记录名称、用途、拥有者、使用频率和是否已实现，先合并重复项，再谈大规模建设。
02 属性要使用业务语义，而不是视觉描述
不要只用“蓝色按钮、灰色按钮”区分变体。更稳定的属性是primary、secondary、danger、loading、disabled等语义。颜色未来变化，业务意图仍然成立。
设计变体和前端Props应尽量同名同义，避免Figma叫Type，代码叫Variant，文档又叫Style。
设计与代码对齐清单
| 层面 | 设计侧要定义 | 前端侧要实现 |
|---|---|---|
| Token | 颜色、字号、间距、圆角、阴影语义 | 变量、主题与构建输出 |
| 属性 | 尺寸、层级、状态、图标位置 | Props、默认值与类型限制 |
| 状态 | Hover、Focus、Disabled、Loading、Error | 交互、键盘、ARIA与反馈 |
| 内容 | 字数、空值、截断、换行规则 | 校验、溢出与国际化处理 |
| 响应式 | 宽度变化、折叠和重排 | 断点、容器查询与布局逻辑 |
| 版本 | 变更说明与弃用标记 | 版本号、迁移说明和兼容策略 |
03 状态覆盖比静态像素更重要
一个输入框不仅有默认样式，还包括聚焦、已填、错误、只读、禁用、加载和自动填充。设计只交默认态，开发只能自行补全。
优先把高频交互组件的状态做完整，再扩充低频装饰组件。状态缺失是还原偏差的重要来源。
04 建立可双向核验的文档
设计组件页说明使用场景、Do/Don’t和内容规则；代码文档展示可运行示例、API、无障碍和边界条件。两份文档应互相链接。
评审新组件时，设计和前端一起确认是否已有替代、属性是否可扩展、是否会破坏现有页面。
05 用Token消除“差一点”的重复值
如果间距、颜色和字号仍由设计师手填、开发手抄，一定会逐渐漂移。语义Token把“品牌主色、正文弱色、危险背景”等含义连接到多端实现。
Token不是把所有数值变量化，而是建立可治理的选择集合，并规定谁能新增。
06 版本治理要允许渐进迁移
组件升级可能影响大量页面。重大变更应标记旧版本、提供迁移说明和截止时间，避免一夜之间全部替换。
定期扫描未使用组件、重复样式和旧Token。没有维护机制的组件库，会从效率工具变成新的技术债。
常见问题
Figma组件名称必须和代码类名完全一样吗？
不必逐字符一致，但属性语义和映射关系必须清楚，最好能在文档中直接对应。
先做设计组件还是前端组件？
高频组件建议设计与前端同步定义；已有产品则先盘点现状，避免一边重建一边继续产生重复。
业务组件要不要放进公共组件库？
稳定且跨页面复用的可以；高度依赖单一业务流程的组件可放在业务层，避免污染基础库。
组件库建完为什么还会还原不一致？
常见原因是页面仍用脱离组件的局部样式、状态未定义、Token未同步或版本管理缺失。
如何衡量设计系统是否有效？
可观察复用率、交付时间、UI缺陷、重复组件数量、迁移成本和新成员上手时间。
链接复制成功
