一、固化底层设计规范，从根源统一基础元素

1. 建立「不可修改」的基础样式库

   定义团队唯一的基础样式集合，嵌入设计工具（如 Figma）的「本地样式」中，所有组件必须基于此创建，禁止手动输入数值。

   基础元素	规范要求	示例
   颜色系统	分为品牌色、功能色、中性色三类，每类颜色限定数量（如品牌色 2 种、功能色 4 种：成功 / 失败 / 警告 / 信息、中性色 6 种：从黑到白的渐变灰）；禁止新增非规范颜色	主按钮用品牌主色#1877F2，禁用状态用中性灰#C9CDD4
   字体系统	限定项目字体（最多 2 种），明确字号层级（如标题 20px→正文 14px→辅助文字 12px）、字重（仅用 400/500/700 三级）；所有文本样式必须绑定字体样式库	正文统一用PingFang SC 14px 400，标题统一用PingFang SC 20px 700
   间距 / 网格系统	强制遵循8px 网格原则（移动端可兼容 4px），组件内边距、组件间间距必须是 8px 的倍数；禁止出现 5px、7px 等不规则数值	按钮内边距统一为16px 8px（左右 16px，上下 8px），卡片内边距统一为24px
   通用视觉属性	统一圆角半径（如按钮 4px、卡片 8px、弹窗 12px）、阴影层级（如浮层阴影0 4px 12px rgba(0,0,0,0.1)，卡片阴影0 2px 8px rgba(0,0,0,0.08)）	所有容器类组件（卡片、弹窗）圆角不超过 12px，避免 “有的圆角有的直角”
2. 统一组件的「结构模板」

   所有组件遵循相同的结构逻辑，避免因结构差异导致的视觉不一致。例如：
   • 所有按钮的图标位置统一：图标在文字左侧，间距固定为 8px；
   • 所有输入类组件的提示文字位置统一：错误提示在组件下方，间距 8px；
   • 所有卡片的内容排版统一：标题在上、内容在下，标题与内容间距 12px。

二、统一组件设计规则，实现「视觉 + 交互」双一致

1. 同类组件的视觉特征一致
   • 形态统一：同类型组件的比例、结构完全一致。例如：所有单选框都是圆形，所有复选框都是方形；所有开关组件的尺寸都是40px*24px。
   • 状态样式统一：所有组件的同类状态，视觉反馈必须一致。例如：
     • 「hover 状态」：所有可点击组件（按钮、卡片、菜单）统一为「颜色加深 5% + 无额外阴影」；
     • 「禁用状态」：所有组件统一为「透明度 50% + 鼠标指针为 not-allowed」；
     • 「选中状态」：所有选择类组件（单选、复选、标签）统一用品牌主色作为选中标识。
2. 同类组件的交互逻辑一致

   交互一致性是用户体验的核心，避免 “这个按钮点击是跳转，那个按钮点击是弹窗” 的混乱。
   • 操作反馈一致：点击组件的反馈统一（如按钮点击时缩小 1%，输入框聚焦时加蓝色边框）；
   • 交互行为一致：同类组件的交互逻辑相同。例如：所有下拉菜单点击后向下展开，所有弹窗的关闭按钮都在右上角且点击后立即关闭；
   • 响应式行为一致：组件在不同终端（移动端 / 平板 / PC）的适配规则统一。例如：按钮在移动端自动缩小尺寸，输入框在移动端宽度 100% 自适应。

三、标准化命名与管理，打通「设计 - 开发」协作链路

1. 组件命名遵循「统一规则」

   采用 **「类型 - 功能 - 属性」** 的命名结构，禁止使用模糊或个性化名称，确保设计师和开发能 “见名知意”。
   • 推荐规则：组件类型-功能描述-属性参数
   • 示例：

     组件	规范命名	错误命名
     主按钮（中等尺寸）	btn-primary-md	提交按钮/蓝色按钮
     带图标的搜索输入框	input-search-icon	搜索框/带放大镜的输入框
   • 关键原则：避免同义词（如 “提交” 和 “确认” 统一为 “提交”）、避免层级混乱（如 “基础组件” 和 “复合组件” 分开命名）。
2. 设计组件与前端组件「一一映射」
   • 设计侧组件名 = 前端侧组件名 + 属性，例如：设计侧btn-primary-md对应前端侧Button type="primary" size="md"；
   • 组件属性命名统一，例如：设计侧的 “主 / 次 / 幽灵” 对应前端的type="primary/secondary/ghost"，避免 “设计叫主按钮，开发叫默认按钮” 的错位。

四、工具强制保障，用「技术手段」替代「人为约束」

1. 组件化封装：禁止手动修改实例
   • 将所有组件设为「可复用组件」，团队成员只能调用实例，不能直接修改实例的样式（如改颜色、改间距）；
   • 用 **「变体功能」** 整合组件的所有状态和属性，例如：一个按钮组件包含 “类型 + 尺寸” 的所有组合，避免创建多个相似组件；
   • 开启 **「自动布局」和「约束规则」**：组件内部间距自适应，拖拽时保持比例，避免在不同页面中变形。
2. 样式库锁定：禁止新增非规范样式
   • 将基础样式库（颜色、字体、间距）设为「团队库」，并锁定修改权限（仅维护小组可编辑）；
   • 禁用 Figma 的「本地样式」创建功能，强制所有样式从团队库中调用，避免有人私自添加颜色或字体。
3. 版本管理：避免混乱迭代
   • 组件库采用语义化版本号管理（如 v1.0→v1.1→v1.1.1），主版本更新（v1→v2）需全员评审，次版本更新仅新增组件不修改旧组件；
   • 每次更新发布变更日志，明确新增 / 修改 / 删除的组件，确保团队成员使用同一版本的组件库。

五、团队流程兜底，建立「评审 + 反馈 + 培训」机制

1. 建立「组件评审小组」
   • 由资深设计师 + 前端开发组成，负责组件的新增、修改、下线评审；
   • 任何新组件必须提交「设计稿 + 使用场景 + 属性说明」，评审通过后才能加入组件库，避免 “为了特殊需求破坏统一规范”。
2. 常态化「一致性检查」
   • 在项目评审中，加入 **「组件一致性检查项」**：核对页面中的组件是否来自团队库、样式是否符合规范、命名是否统一；
   • 定期收集团队使用反馈，针对高频问题（如 “某组件状态缺失”“某命名易混淆”）优化组件库。
3. 全员培训与宣贯
   • 新人入职必须完成「组件库规范培训」，并通过小测试（如 “找出页面中 3 处不一致的组件”）；
   • 每月组织一次「组件库使用分享会」，讲解最佳实践和常见错误，强化团队的一致性意识。

六、避坑指南：3 个破坏一致性的常见错误

1. 为特殊场景修改核心组件：遇到特殊需求时，不要直接改核心组件的样式，而是创建「扩展组件」（如 “营销专用按钮”），避免影响全局；
2. 忽略边缘状态的一致性：只设计组件的默认状态，漏掉 hover、禁用、加载等状态，导致开发自行脑补样式；
3. 设计与开发脱节：设计组件不考虑技术实现，开发还原时随意调整样式，最终导致 “设计稿一致，线上页面不一致”。