领猫SCM – Design System
一、项目背景
老版本的项目存在明显问题：页面视觉不统一，布局结构、色值、尺寸、间距无统一标准，新页面重复造轮子。
基于以上痛点，我们在2023年的时搭建了领猫设计系统，表象上样式的规范都有了，但是在工程化上做的还不足，没有Design Token的概念（设计软件用的是MasterGO，那时候软件里还没有变量的概念）。最近，MasterGo也增加了变量功能，正好做下设计系统的升级。此次升级以标准化 Design Token 为底层，统一全平台视觉、交互、布局规则，实现一套组件适配双主题、双密度，打通「设计 – 前端」同源变量协同链路。
二、设计思路
参照原子理论的思路，将系统拆解为 5 个层面：原子、分子、组织、模块、页面。首先从最基础和核心的原子入手，包括颜色样式、文字样式、特效样式、间距样式、图标等，在底层原子基础上构建出上层分子、组织、模块，最终落地承载业务的页面。
以标准化 Design Token 为底层基石，将全平台的设计语言进行工程化管理。Token分三层架构：
- Primitive：基础层存储原子化数值（如色值 #0058ff、间距 8px），避免硬编码；
- Semantic：语义层赋予基础值具体用途（如surface-page、text-primary），连接设计与业务逻辑；
- Component：组件层基于语义 Token 组合出的具体组件样式变量（如btn-primary-bg），直接驱动 UI 渲染；
这种架构让设计系统从“静态样式库”进化为“动态逻辑层”，设计师专注定义基础与语义规则，开发者直接使用组件Token 构建组件。双方基于统一语言协作，减少沟通歧义，提升交付速度。最终达到设计系统在保证统一性的基础上，兼具灵活可扩展性。
三、设计系统基础规范
设计系统包括5个系统（色彩系统、字体系统、间距系统、圆角与投影系统），2个模式。所有基础规范中的颜色、数值及对应模式的值都存入对应原子Token。
- 色彩系统：品牌色、功能色、中性色、多主题色
- 字体系统：字族、字阶、字重、行高
- 尺寸与间距系统：高度、内间距、外间距
- 圆角与投影系统：
- 视觉主题模式：亮色模式/暗色模式，默认亮色模式；
- 布局密度模式：紧凑模式/宽松模式，默认紧凑模式。
四、Design Token
在确定基础设计规范后，使用Design Token的第一件事就是要确定Design Token怎么写，怎么分层级？怎么命名？
4.1 Token怎么分层？
行业目前存在 4 套主流分层方案：单层扁平式、两层分层、三层标准分层（Primitives/Semantic/Component）、四层扩展分层。
基于目前系统现状（多主题色、亮色/暗色模式、宽松/紧凑模式）和产品规模现状（产品线规模），目前来说三层是最合适的。
- 第一层 Primitive Token：唯一存放原始色值、尺寸、圆角、阴影，所有上层变量仅允许引用，亮色 / 暗色、宽松 / 紧凑仅在此层修改数值；
- 第二层 Semantic Token：赋予场景含义，设计师绘图直接使用，屏蔽数字色阶记忆成本；
- 第三层 Component Token：绑定单一组件专属样式，隔离组件样式逻辑，修改按钮不会影响表格、表单。
具体在mastergo里，如何建集合呢？拆分4套变量集合，每套集合下3个分组。模式根据集合特性来，色彩集合下分亮色/暗色模式，文字、尺寸&间距下分紧凑/宽松模式，圆角&阴影无模式切换。
4.2 Token怎么命名？
结合B端产品多状态、多组件、双模式、多主题、长期迭代的特性，三层分层命名体系是目前最优解。该方案完美规避单一命名规则的所有短板，兼顾可读性、可维护性、拓展性、主题适配性，完全适配企业级B端设计系统全场景落地。
4.2.1 基础层（Primitives）采用【表象梯度命名规则】
标准命名公式：[色相/类型]-[梯度]
- 品牌色：brand-500、brand-600
- 功能色：danger-500、success-500
- 中性色neutral-100、neutral-900
- 尺寸类：radius-md、space-8
核心规则：只描述视觉原始属性（色相、深浅、尺寸），不绑定任何业务、场景、组件、状态，纯原始变量，用来做全局底层数据源，允许“以色为名”。
4.2.2 语义层（Semantic）：采用【功能语义命名规则】
核心规则：只描述用途、功能、视觉角色，彻底抛弃色相/表象，严格遵循「命名描述用途，不描述外观」行业铁律，统一全站视觉规范。
标准命名公式：[视觉角色]-[功能/状态]
落地示例：
- 文本语义：text-primary、text-placeholder
- 背景语义：brand-fill、danger-bg
- 边框语义：border-default、danger-border
- 全局状态：brand-hover、brand-active
4.2.3 组件层（Component）：采用【结构化场景+状态命名规则】
核心规则：采用「从泛到精」结构化语序，精准绑定具体组件 + 部位 + 交互状态，专门解决组件多状态、差异化样式，隔离组件样式污染。
标准命名公式：[组件]-[类型/部位]-[状态]
落地示例：
- 主按钮全状态：btn-primary-bg / btn-primary-hover-bg / btn-primary-disabled-bg
- 默认危险按钮：btn-default-danger-text / btn-default-danger-hover-border
- 组件禁用态：btn-success-disabled-text、btn-danger-active-bg
使用边界：只映射语义层，不直接引用基础层；所有组件 hover/active/disabled 全状态统一收敛在此层。
4.3 Primitive – 色彩Token
4.3.1 品牌色
品牌色分为8档色阶：50/100/200/300/400/500/600/700。暗色 Mode 下整套色阶同步替换深色适配色值，上层语义变量无需改动。
4.3.2 功能色
功能色分为4种类型：成功 / 警告 / 危险 / 信息；每种类型8档色阶：50/100/200/300/400/500/600/700。暗色 Mode 下整套色阶同步替换深色适配色值，上层语义变量无需改动。
4.3.3 中性色
中性色分为11档色阶：0/50/100/200/300/400/500/600/700/800/900。明暗映射规则：亮色数字越大颜色越深，暗色数字越大颜色越浅，完美双向适配页面层次。
4.3 Primitive – 尺寸Token
尺寸类分为：通用尺寸（Space间距、Height高度、Padding内间距）、ICON图标尺寸。紧凑/宽松模式切换是通过语义层的档位映射变化。这里不同于颜色类的亮色/暗色模式切换，颜色的亮/暗切换是原子层值的替换，同一个色阶在不同模式下是不同的颜色。
4.4 Primitive – 圆角&投影Token
圆角&投影Token不受「亮色 / 暗色主题」、「宽松 / 紧凑密度」影响，4 种模式数值完全统一。
4.5 Semantic & Component Token 映射方案
- 语义 Token：颜色、文字、尺寸、圆角/投影影，全部引用底层，不存储独立值；
例：fill-brand-hover = brand-400 - 组件 Token：绑定按钮、表格、输入框等组件，隔离组件样式；
例：btn-primary-bg-hover = fill-brand-hover - 落地优势：仅修改 Primitive 底层色值，全域按钮、表格、标签、文字全部自动同步换肤，无需逐个修改组件样式。
五、基础组件
