设计稿颜色交付给前端时要核对什么

最基础的是明确格式，也就是当前色值究竟以 HEX、RGB、RGBA、HSL 还是 token 名称为准。其次要给出它在什么场景下使用，例如按钮、正文、边框、背景、标签还是图表。

如果一个颜色还涉及透明度、混合层、渐变或模糊遮罩，这些信息也要一起交代。因为前端拿到一个孤立的纯色值，并不能还原完整视觉结果。

最常见的遗漏是状态层级。设计稿里可能只标了主按钮颜色，但没有标 hover、active、disabled、浅底按钮和深底按钮。另一个高频遗漏是渐变参数，尤其是角度、stop 位置和透明度。

还有一种情况，是颜色本身没问题，但没有说明它是临时页面专用色，还是应该沉淀为长期 token。前端一旦误解，就会把临时色带进全站体系。

• 按钮、标签、边框和背景的状态层级最容易漏。
• 透明度色和渐变参数必须完整交付。
• 临时色还是系统 token，要在交付里说清楚。

更稳的方式不是堆更多截图，而是把颜色沉淀成有角色的 token 或清单，例如主色、浅背景、深按钮、正文、弱提示和禁用态分别叫什么、用在哪里。

这样前端就不是在抄一个个散色值，而是在实现一套颜色规则。真正需要变更时，也更容易只改 token，而不是全站搜索替换。

• 优先交付带角色说明的 token，而不是零散色值。
• 关键组件最好补状态说明和示例。
• 正式开发前，先把颜色规则对齐，比后期返工省很多。