相信大家对于 Design Token 的概念已不陌生，但是仅是了解了这些概念，很多同学在理解和使用 Token 时依旧会有很多问题。今天就再给大家详解几个关于 Design Token 的常见问题：
- Design Token 所对应的是每一个组件么？
- Design Token 算不算组件的设计规范呢？
- Design Token 是不是只要设计师了解和掌握就可以了？
Q1 Design Token 所对应的，是每一个组件么？
不是的。Design Token 对应的是组件的“属性”。“属性”就是事物的特征和特性。举个例子：
你可以用属性来描述一只兔子：颜色是白色；外形是长耳朵、短尾巴等等。同样的道理，一个组件也可以从它的颜色、圆角、描边等方面来描述，这些就是组件的属性：
Design Token 所对应的正是组件的属性（颜色、圆角、形状、等级、描边等），相当于是将组件的特性和属性做了提取并进行统一的整理、编组和命名。
因此也可以说 Design Token 的精髓就在于：将共性特征 / 属性变成了可以操控的变量。我们常见的 Token 使用方式是：
下图中 5 个组件的圆角都是 4px，且这些圆角都用于组件的背景层，那么它们就可以绑定和使用同一个圆角的 Token，命名可以是：corner-background-small，其所对应的数值就是 4px。而以后如果你想要将这 5 个组件的圆角都改为 8px 时，你只需要更改一次 Token 所对应的数值：从 4 改成 8，就可以让这 5 个组件的所有圆角都从 4px 变成 8px：
Q2 Design Token 算不算是组件的设计规范呢？
可以算是一种设计规范，不过严格来说，Token 和设计规范也有一定的区别：
1. 设计规范：
是一种设计和使用组件时的规则和约束。
比如你制定的设计规范可以是：组件的报错状态的颜色统一使用 # F82B35 这个颜色。这就意味着组件库中的所有组件的报错状态的颜色都要使用这个颜色。
2. Design Token：
是一种组件系统的底层搭建方法，可以帮助设计师更好地执行设计规范。
正是因为设计规范中规定了所有组件的报错状态都统一使用一种颜色（#F82B35 ），这个颜色特征就可以被规定成一个 Token，名称可以是：color-function-error，在设计所有组件的报错状态时使用。
不过，由于现实情况中我们的业务需求五花八门，设计规范不可能完全涵盖所有场景，这时 Token 也可以被看作是一种设计上的规则，对设计产出起到规范和约束的作用。比如：
①在做新的组件或优化组件时：
当某一个旧的组件需要做重新优化或者有新的组件要加到组件库时，设计师就需要注意将被调整的组件的所有属性都绑定到对应的 Token，以此来保证组件设计的准确性和一致性。
②在做设计需求，没有合适的组件时：
当组件库中没有合适的组件来满足设计需求时，设计师就需要重新设计其它的元素和样式来完成设计需求。这时设计师在选择和使用颜色、字体和圆角等属性特征时，就需要按照已有的 Token 来绘制设计元素和产出设计稿，以保证产品设计上的一致性和整体性，在之后的设计迭代和改版上也会更方便。
Q3 Design Token 是不是只要团队的设计师了解和掌握就可以了？
不是的。团队中的设计师和开发都需要了解和使用同一套 Design Token。
Token 和组件一样，最重要一步也是代码化，做了代码化的 Token，生命才是完整的，产品的设计与开发过程才是通畅的，Token 也才会起到最大的提效和规范作用。
如果你希望设计和开发的对接更加顺畅，可以试试这样做：
- 设计师在前期做 Token 列表和命名方式时，就可以邀请开发一起加入，听听他们的意见；
- 如果 Token 在设计侧有更新，一定要及时同步给所有相关的设计师和开发，做同步调整；
- Token 的维护人员最好有唯一的管理权限，开发侧和设计侧各一个，避免其他人误操作。
欢迎关注作者微信公众号：「长弓小子」
