提取颜色实战:把设计稿里的十六进制颜色整理成色板

接手一个跑了两年的前端项目时,我习惯先做一件事:把全站用到的十六进制颜色全部捞出来。结果往往很难看。一个号称只有主色、辅色、灰阶三套色的设计系统,实际代码里能数出四十多种十六进制值,光是灰色就有 #999、#9a9a9a、#9b9b9b、#999999 四个几乎一样的写法。这种混乱不靠人眼能查清,得先把颜色提取出来,去重,再排序成一张色板,才看得见全貌。

为什么要先提取再治理

颜色蔓延是慢慢发生的。每个人随手吸一个色就写进样式表,没人回头核对它是不是已经存在。等到要做主题切换、要加深色模式、要统一品牌色时,这些散落的十六进制值就成了硬障碍。先提取成一份清单,你才能回答几个关键问题:这个稿子到底用了多少种颜色,哪些是重复的近似色,哪些只出现一次属于一次性临时色。把这些数据摊在面前,治理才有依据,而不是凭感觉删改。

用正则匹配十六进制颜色

十六进制颜色的形态很固定:一个 # 后面跟 3 位或 6 位十六进制字符。最常用的匹配规则是 /#([0-9a-fA-F]{6}|[0-9a-fA-F]{3})\b/g,先匹配 6 位再匹配 3 位,顺序不能反,否则 #1a73e8 会被先吃掉前 3 位 #1a7 留下错误的尾巴。带透明度通道时会出现 8 位或 4 位,可以扩成 {8}|{6}|{4}|{3}。注意 #header 这种 id 选择器也会被 # 开头误抓,所以提取出来的结果一定要带校验状态,让你能区分真颜色和误命中,而不是信任一个看不见的过滤器。

一段 CSS 提取出色板

假设你从某个组件样式里复制了这么一段:

.btn { background: #1a73e8; color: #fff; }
.btn:hover { background: #1A73E8; }
.card { border: 1px solid #e0e0e0; }
.muted { color: #999; }

把它粘进提取器,得到的去重色板是:#1a73e8、#fff、#e0e0e0、#999。注意 #1a73e8 和 #1A73E8 大小写不同但是同一个颜色,规范化后只留一条;#fff 和 #999 是 3 位简写,你可以选择展开成 #ffffff、#999999 再统计。原始这 5 处颜色写法,最终归到 4 个唯一值,这就是一次最小的色板审计。

审计设计稿用了多少种颜色

把整份编译后的 CSS,或者从 Figma 导出的样式文本,整段粘进 十六进制颜色提取器,开启去重和排序,你会立刻看到唯一颜色的总数。我做过的一个真实项目,提取前样式里写了 312 处颜色引用,去重后只剩 38 个唯一值,而其中真正进入品牌规范的不超过 12 个。剩下那 26 个就是要清理的对象:近似灰、临时调试色、复制别处忘改的值。带行号的输出让我能跳回原文,逐个核对到底是哪一行写歪了。

迁移到 CSS 变量与设计系统规范化

色板清出来之后,下一步是把它沉淀成 CSS 变量。把去重后的 12 个核心色导出成 TypeScript union 或纯列表,对照命名,写成 --color-primary: #1a73e8;、--color-text: #1a1a1a; 这样的令牌,再回到样式里把散落的硬编码十六进制值替换成 var(--color-primary)。替换完别忘了再跑一遍提取,确认样式表里不再出现裸的十六进制值,只剩变量引用,这次的输出应该接近空,说明迁移干净。如果团队已经有一份变量清单,可以用 CSS 变量列表校验器 核对命名是否规范、有没有重名或拼错的令牌。这一步做完,设计系统才算从"约定"变成"代码里能查的事实"。

颜色治理不是一次性工程,而是每次提取都让色板更收敛一点。提取、去重、审计、迁移这套流程跑顺了,新人随手吸色就再也藏不住,所有偏离品牌色的写法都会在下一次提取里现形。

---

Made by Toolora · Updated 2026-06-13