如果你的设计系统还没有使用 semantic tokens(语义令牌)，你就错过了一个提升可扩展性和效率的关键工具。

是什么

Semantic tokens 能让你创建一个结构化、灵活的系统，其中的设计决策由用途而非原始数值来定义。你无需为按钮或文本指定固定的色值，而是使用像 primary-button-bg 或 warning-text 这样的令牌。

这意味着，你的主按钮背景色将不再是 blue/500，而是 primary-button-bg，它的值关联到 blue/500（而 blue/500 又对应着 HEX 色值 #5A8DD7）。

我们用一个可视化示例来试试看，不过要记住，在实际操作之前，很难体会到它有多实用。

通常，你会这样为元素应用变量：

现在，假设你想把 component-2 中的描边改为 #0D0D0D。你需要这样操作：

虽然看起来改动不大，但当你开始扩展这套系统时，很快就会难以分清哪个 HEX 值应该应用到哪个组件或元素。

相反，你需要应用 semantic tokens 来明确每个元素应该使用哪些变量。

这样更新会更容易——只需修改一次令牌，就能在各处生效！让我来演示一下……

为什么

可扩展性

随着设计系统的不断壮大，跨多个组件手动更新样式会变得难以管理。Semantic tokens 能让你在一处进行修改，并让改动在整个系统中保持一致地生效。

比如，你决定要更改主色，但只针对 page-title 组件。如果你正确地应用了 semantic tokens，就无需修改组件本身，只需在变量窗口中更改与之关联的令牌即可。

或者，你发现 #black/600 作为设计系统中的背景色效果不佳。那么，你只需前往变量面板，将 surface-alt 替换为另一个原始令牌即可。

一致性与可维护性

通过关注功能而非具体数值，semantic tokens 能确保产品在整体上呈现更统一、一致的外观。你不再需要猜测或记忆该使用哪个数值——只需选择名称合适的 semantic token 即可。

想不起来主边框该用什么颜色？很简单，就是 stroke-primary。

主题化与定制

无论是引入深色模式、品牌定制，还是对不同样式进行 A/B 测试，semantic tokens 都能简化流程。你无需大范围修改原始色值，只需在更高层级替换令牌即可。

面向未来的设计系统

通过在设计与实现之间建立清晰的抽象层，semantic tokens 让你的系统能够随着时间推移不断演进，而不会破坏现有设计。

需要发布一套新的配色方案来匹配公司更新后的品牌形象？只需修改你的原始数值即可。

如何实现

定义核心设计令牌

首先，为颜色、排版、间距和其他关键设计属性创建基础令牌。

通常，我会在一个名为 primitives 的独立集合中创建这些原始值。

专业小贴士：使用 Tailwind CSS Color Generator 快速加载主色调色板，并使用 Export/Import Variables 插件在不同文件之间导入和导出你的配置。

将核心令牌映射到语义令牌

接下来，定义描述这些值在界面中如何被使用的 semantic tokens。它们充当抽象层，让你在不影响底层结构的情况下更轻松地更新样式。

搭建 semantic tokens 需要时间，你的方法可能也需要在实践中不断完善。然而，一旦落地，它们将显著提升可扩展性和可维护性，减少不一致并加速开发。这是一项值得的投入。

限制变量的作用范围

最后，限制某些变量可应用到的元素。要做到这一点，首先前往你的 primitives 并将其全部禁用。

然后，逐一检查你的令牌并定义其作用范围。在下面的示例中，我将与 border 相关的令牌限制为仅适用于描边元素。

现在，当我想为描边应用变量时，只会显示适用的变量，让你能超级轻松地选对变量！

这不是一份完整教程

如果你想进一步了解如何在设计系统中应用 semantic tokens，建议先从 来自 Figma 的这篇教程看起。之后，理解你想如何使用 semantic tokens 的最好方法，就是亲自尝试并在你的设计系统中进行实践。

是的，搭建 semantic tokens 可能是一个漫长而繁琐的过程，但收益是巨大的。如果你的设计系统还没有使用 semantic tokens，我建议你尝试一下！

请记住：关键在于 结果而非产出。关注团队真正需要的东西，而不是追求完美的文档。