设计系统与组件库

设计系统是把设计语言、组件、规范与工具整合适配的活的产品，目标是让团队以更低成本产出一致体验。三者是包含与演进关系。风格指南是最早形态，静态描述视觉规则如品牌色、字体用法，只回答长什么样。组件库是可复用的实现集合，设计侧是 Figma 组件，代码侧是 React 等组件，回答用什么拼。设计系统则在这两者之上增加：设计原则与内容语气、设计 Token 体系、组件的行为规范与使用边界、无障碍标准、贡献与治理流程、版本发布与沟通机制。判断一个系统是否成熟，看的不是组件数量而是治理：有没有人维护、变更如何决策、新需求如何贡献进来。组件库只是设计系统的产出物之一。面试时能讲清这个演进关系，并强调系统是流程与人的协作而不只是文件包，就抓住了这个概念的核心。

Token 通常分三层。第一层是全局令牌即原始值，如色值十六进制、字号数值、间距数值，是设计的原材料，命名与外观绑定，如蓝色五百。第二层是别名令牌即语义层，按用途重命名原始值，如主色、背景页面、文字次要、间距组件内，这一层表达的是角色的含义而不是外观。第三层是组件令牌，组件内部引用语义令牌并可被主题覆盖，如按钮背景、卡片圆角，让组件皮肤可被主题定制。分层的原因有三：一是多主题支持，深色模式、多品牌、白标场景只需要改语义层的映射，组件层不动，成本最低；二是语义沟通，团队说文字次要色直接明白用途，避免出现三十个灰色各自为政；三是与代码同步，三层结构与前端样式变量的组织方式一致，设计和工程可以建立同名映射，还原偏差趋零。管理上需要 Token 字典文档记录每层定义与使用规则。这是设计系统岗位的核心考点。

推广难是设计系统的普遍问题，策略分五条。一是降低使用成本，组件要好用易找，Figma 库结构清晰命名可搜索，文档配真实场景范例与可复制代码，找组件超过三十秒用户就会自己画。二是证明收益，展示使用系统后交付速度与走查问题下降的数据，让业务负责人看到团队效率而非额外约束。三是梯度参与，把业务设计师纳入贡献者体系，组件需求的提案权开放，公共组件由系统团队与业务共建，被采纳的组件贡献者署名， ownership 带来认同。四是治理兜底，设计评审与走查环节加入系统引用检查，未使用组件需说明理由，形成软约束；同时系统团队承诺响应时效，组件问题修复有 SLA。五是渐进迁移，存量页面按改版节奏逐步替换，不强推大重构。核心理念是设计系统是内部产品，业务团队是用户，要按产品运营的方式做增长与留存。

处理多样需求的方法是分层开放。第一步穷举属性，把组件的变化维度参数化为属性，尺寸、类型、状态、图标位、内容槽，用变体管理，覆盖常见组合。第二步提供槽位与组合能力，组件内部留出插槽让业务放自定义内容，通过组合而非复制解决个性化。第三步主题层定制，颜色圆角等外观通过 Token 映射，业务换主题不动组件结构。允许业务覆盖的判断标准有三条：覆盖的是表现还是行为，只改颜色字号等表现层可以开放 Token 覆盖，改交互行为与信息架构原则上不开放，因为行为一致性是系统底线；需求是否具有普适性，多个业务线都提的相同需求应该进公共组件迭代，单一业务的一次性定制宁可 fork 局部实现也不污染公共库；是否影响无障碍与品牌识别，破坏这两条红线一律拒绝。治理上建立豁免流程，覆盖需登记原因与期限，定期回收。这个题考察系统思维与边界的把握。

版本管理遵循语义化版本的思路。设计资产与代码组件同步发版，主版本号代表破坏性变更，如组件 API 改名、Token 删除、视觉大改，业务必须手动迁移；次版本号是向后兼容的新增，新组件、新属性；修订号是缺陷修复与微调。发布机制上，Figma 库使用发布功能带说明，代码侧走包管理器发版，两侧版本号对齐并维护映射表。破坏性变更的沟通规范：提前一至两个迭代在变更日志与团队频道公告，附迁移指南与前后对照；旧版本保留一个过渡期并标注弃用标记，不是立即删除；提供自动迁移手段尽可能降低手工成本，如 codemod 脚本或一键替换；设置答疑窗口收集迁移问题。另外要维护系统的 changelog 页面，任何视觉调整都配截图，让业务能追溯为什么变了。成熟团队的发布节奏固定，如双周一小版本、季度一大版本，可预期性本身就是信任。这题考的是把系统当软件工程来治理的意识。