什么是token，为什么组件命名用到token ？

这是Design System里面最容易让人困惑的概念。

很多设计师第一次接触 Token 都会问：

"颜色就是颜色，为什么要搞个 Token？"

真正理解 Token 后，你会发现Token 根本不是为了设计师，而是为了让设计、代码、产品三方说同一种语言。掌握 Token 的设计方法，是设计师从关注单个组件，走向构建完整 Design System 的重要能力。

一、Token 到底是什么？

Design Token 是设计决策的最小可复用单元—— 把颜色、间距、字号、圆角、边框等等设计属性，以

具有语义名称的变量形式进行管理，使设计规范能够在设计工具、代码和不同平台之间保持一致。所有组件都引用这些变量，而不是写死具体数值。

类比：就像做菜不用 "放一点盐"，而是用 "小勺 / 大勺" 标准化。Token 就是设计界的标准量具。

举个实际代码例子

第一步：全局定义 Design Token

（通常在主题文件theme.css里统一管理）

第二步：组件里引用 token

 为什么？

因为以后只改：

整个系统全部更新。

Design Token也是一样。

例如：

传统方式：

现在：

这里的 color.primary 就是Token，它代表：“品牌主色”不是“#1677ff”。

二、为什么组件命名必须用 Token？

在 B 端系统（尤其是包含复杂数据大屏、表格，并且可能会有暗色系浅色系切换的系统）里，如果不用 Token 命名，系统根本无法维护。

最大问题：修改成本极高

举个真实需求。

产品经理说：“Primary Button改绿色”

很多新人：

结果整个系统link、icon、progress等全部绿了。

因为都引用Primary。

但是：如果

改：

只有Button变。

其它，完全不动。

所以：

Component Token就是给组件自己的"局部变量"。

沟通语言的统一（告别“猜色值”）

如果没有 Token，设计师给开发标注的是：“按钮背景色：#1890FF”。 开发如果在写代码时，不小心敲成了 #1890FE，肉眼根本看不出区别，但代码里就多了一种颜色，时间久了，系统里会有几百种相近但不相同的蓝色。

有了 Token，设计师说：“按钮背景用 button-primary-bg”。开发代码里写的也是 var(--button-primary-bg)。双方沟通的不再是物理数值，而是语义，绝对不会错。

实现一键换肤（Dark Mode ）

要做深色模式，不用改任何组件代码，只需要替换 token 的值：

多端复用 (Web / iOS / Android)

产品如果要在电脑网页（Web）、苹果手机（iOS）和安卓（Android）上同时开发。 iOS 程序员不懂 CSS 里的 HEX 色值，Android 程序员可能习惯用 XML 配置颜色。 Token 就是一个中介。Figma 导出一份 Token 的 JSON 文件，通过工具（如 Style Dictionary）可以自动翻译成：

• Web 用的 CSS Variables
• iOS 用的 SwiftUI Colors
• Android 用的 XML Resources

三、如何使用？

成熟 Design System 通常采用三层模型：

核心逻辑链：Component Token (绑定具体组件) 映射到 Semantic Token (表达设计意图) 映射到 Primitive Token (定义物理像素或色值)。

我们可以在figma自带的Local Variables中创建变量，或者使用Token Studio for Figma插件。

第一层 Primitive Tokens (基础 Token)

这是最底层、最客观的物理值。它们不携带任何业务属性或使用场景，只描述“它是什么”。

• 命名方式： 通常基于视觉属性本身（如颜色名+色阶、尺寸+具体数值）。
• 示例：color-Blue-1 = #326BFB。
• 作用： 充当整个系统的“调色盘”和“零件库”。在规范的协同流程中，开发者和设计师都不应该在具体的业务组件中直接引用 Primitive Token。
• 
  

第二层 Semantic Tokens (语义 Token)

这是承上启下的一层，也是整个 Token 体系中最核心、最有价值的一层。它不关心绝对值是什么，只关心“这个变量用来干什么”。它通过映射直接指向 Primitive Token。

• 命名方式： 在标准的 Design Token 规范中，Semantic 层的颜色通常会按照 UI 元素的构成属性 划分为至少 4 个大类：

1. Background (背景)：填充面积大的色块。
2. Text (文本)：用来阅读的字体。
3. Border (边框/分割线)：线条。
4. Icon (图标)：有时和文本共用，但复杂系统会拆分。

基于使用场景、设计意图或交互状态。结构通常是：[领域] - [属性] - [意图/状态]。

• 示例：color-primary-bg-default = color-blue-6（禁止出现具体的组件名）
• 
  
• 作用： 实现主题切换（如暗黑模式）和品牌换肤的灵魂。比如切换到暗黑模式时，你只需要让 color-primary 映射到另一个深色阶的 Primitive Token，所有使用了 color-primary 的地方都会自动更新，而无需全局查找替换色值。
• 
  

第三层 Component Tokens (组件 Token)

这是最顶层、最具体的一层。它们专门为某个特定的 UI 组件（如 Button、Table、Modal）定制，通常指向 Semantic Token（偶尔也会直接指向 Primitive Token）。

• 命名方式： 组件名 + 属性 + 状态。
• 示例：button-primary-bg-hover = color-primary-hover
• 作用： 提供极其精细的局部控制。假设前端使用了现成的组件库，而业务线要求所有数据看板的表格表头背景色必须是某种特定的深色，但其他控件的背景色保持不变。如果只用 Semantic Token，修改背景变量会牵一发而动全身；但有了 Component Token，你只需单独覆盖 table-header-bg 即可，完全不影响全局系统。

四、进阶技巧

文件级拆分

不要把所有的变量和最终的业务页面放在同一个 Figma 文件里。建议你采用“多文件链接”的架构：

文件 A：基础规范 (Foundations) —— 这是你的“数据库”。所有的 Primitive 和 Semantic Variables 都在这里创建。

文件 B：组件库 (Components) —— 引入文件 A 的变量，搭建 Input、Table 等组件。

文件 C：业务页面 (UI Design) —— 设计师平时干活的地方。引入文件 A 和 B。

使用“斜杠/ ”分组

Figma 原生支持通过命名中的 / 自动生成文件夹目录。

隐藏 Primitive 变量（防止被直接选用）

设计师在画界面的时，绝不应该直接选择 blue-5，他们只能选择 color-primary。

操作方法： 在 Figma 的 Variables 面板中，选中 Primitive Colors 这个集合里的所有变量，右键选择 Edit variable，在弹出的面板底部，取消勾选 "Show in publishing" (在发布中显示)。

或者更快的命名法： 在变量名字前面加一个下划线或者点（比如 _blue-5 或 .gray-1），Figma 默认不会对外暴露带有这些前缀的变量。

严格限制变量的作用域 

如果在设置字号的时候，下拉菜单里出现了 radius-container，这会让设计师非常困惑。

操作方法： 选中变量 -> Edit variable -> Number scoping。

对于 radius/container：只勾选 Corner radius。

对于 gap/base：只勾选 Gap (Auto layout)。

对于 padding/card：只勾选 Padding。

Powered by Froala Editor