颜色规范化指南:为什么 #FFF 和 #ffffff 是同一个色

同一个白色,在一个项目里我见过五六种写法:#fff、#FFF、#ffffff、#FFFFFF,还有漏掉井号的 ffffff。它们渲染出来一模一样,但只要拿去做字符串比对,机器会把它们当成五个不同的值。这就是颜色规范化要解决的问题:把同色的不同写法统一成一种标准形态,再做去重、diff 或导入。

三位缩写和六位全写本来就是同一个色

CSS 规范允许十六进制颜色用三位缩写,展开规则是每一位重复一次。#fff 等于 #ffffff,#abc 等于 #aabbcc,#f80 等于 #ff8800。浏览器渲染时会先做这一步展开,所以你眼睛看到的颜色完全一致。

问题出在文本层面。#fff 是 4 个字符,#ffffff 是 7 个字符,大写 #FFF 又是另一串字节。对人来说它们是一个色,对 === 来说它们是三个互不相等的字符串。规范化做的事,就是把人的认知补给机器:统一展开成六位,统一小写,统一带井号。

一个真实的输入输出例

给规范化工具喂一段从主题文件复制来的颜色:

#FFF
#abc
FF8800
#aabbcc

输出会是这样,每一行都被改写成同一种小写六位带井号的形态:

#ffffff
#aabbcc
#ff8800
#aabbcc

#FFF 补成 #ffffff,#abc 展开成 #aabbcc,漏井号的 FF8800 补上井号并改小写成 #ff8800。注意 #abc 和后面的 #aabbcc 规范化后字符串完全相同,这时去重才能正确地把它们合并成一行,不再因为写法不同而漏判。

设计系统去重前为什么必须先规范化

设计系统里最容易出现的就是「重复 token」:两个设计师定义了视觉上一样的色,但一个写 #1A1A1A,一个写 #1a1a1a。直接对 token 表做去重,这两行会被当成不同值各留一份,色板里就多了一个其实多余的颜色。

正确的顺序是先规范化再去重。把所有色值压到同一种形态后,#1A1A1A 和 #1a1a1a 变成同一个字符串,去重才能把它们折叠成一条。我自己在合并两个旧项目的色板时就吃过亏:没规范化直接去重,八十多个色里硬是留下了十几个大小写不同的「假重复」,排查了半天才发现根本是同一批色。先过一遍规范化,这十几条立刻归并,真实色数从八十多降到六十出头。

diff 稳定:让颜色改动一眼能看清

代码评审时,颜色相关的 diff 经常很吵。有人把 #FFFFFF 改成了 #fff,功能没变,但 diff 会标成一行删除加一行新增,看起来像改了颜色。如果团队约定所有颜色统一走规范化形态(小写、六位、带井号),这类纯写法差异就消失了,diff 里剩下的每一处颜色变更都是真的换了色。

这对自动化也友好。CI 里跑一遍规范化校验,任何不符合标准形态的颜色都能被拦下,从源头杜绝写法漂移。

本地处理,不上传任何文件

需要强调的一点:这类清洗经常涉及内部主题、未发布的品牌色,甚至混在文本里的客户数据。规范化全过程,包括解析、校验、去重和导出,都在你的浏览器里完成,上传的本地文本文件只通过浏览器 File API 在当前标签页读取,不会发到服务器。你可以放心把整份导出的色板拖进来处理。

需要更细的拆分流程时,可以配合 十六进制颜色去重工具 把规范化后的列表折叠成唯一值。如果只想跑这一整套规范化和导出,直接用 十六进制颜色规范化工具 就够了,粘进来,选好输出格式,拿走干净的 CSV 或 TypeScript union。

---

Made by Toolora · Updated 2026-06-13