十六进制颜色去重指南:批量 hex 去重,统计设计系统真实用色

打开一个跑了两三年的前端项目,把所有样式表里的颜色值抓出来,你大概率会被吓一跳:同一个品牌蓝,有人写 #1E90FF,有人写 #1e90ff,还有人图省事写成缩写。表面看是几十个不同的色,数下来才发现真正用到的核心色没几种。要精简色板、统一设计 token,第一步不是改颜色,而是先把这堆值去重,看清楚到底有几种色。

为什么 #FFF 和 #ffffff 是同一种颜色

很多人第一次看到 #FFF、#ffffff、#FFFFFF 并排,会以为它们是三种白。其实它们在浏览器渲染出来完全一样,只是写法不同。

十六进制颜色的差异来自两个层面。一是大小写:#FF0000 和 #ff0000 指的是同一个红,因为十六进制里 A 到 F 不区分大小写。二是缩写:三位写法 #FFF 是六位写法 #FFFFFF 的简写,规则是每位字符重复一遍,#F00 等于 #FF0000,#1A2 等于 #11AA22。所以 #FFF、#ffffff、#FFFFFF 这三个值,落到屏幕上是同一个像素颜色,只是被三个人用三种习惯敲了出来。

如果做去重时只做字符串完全匹配,这三个值会被当成三种色保留下来,统计结果就虚高。真正可靠的去重,得先把写法拉齐,再比对。

规范化成六位小写后再比较

可靠的去重逻辑有一个关键步骤:规范化。具体做法是把每个颜色值都先转成统一形态,再判断是否重复。

我用的标准是统一成六位小写。流程分三步:第一步,如果是三位缩写,展开成六位,#F00 变 #ff0000;第二步,全部转成小写,#FF0000 变 #ff0000;第三步,拿规范化后的值做比对键去重。这样无论原始写法是大写、小写还是缩写,只要是同一种色,规范化后都会落到同一个键上,自然合并成一行。

这一步还能顺手揪出无效值。像 #12345 只有五位、#GG0000 混进了非十六进制字符、或者漏掉开头的 #,这些都当不了合法颜色。好的去重工具不会把它们悄悄删掉,而是单独标出来让你复核,免得一个真该保留的色块被误判丢掉。

一个真实的输入输出例子

说再多不如看一遍实际效果。假设你从几份样式表里抓到这样一段:

#FFF
#ffffff
#FFFFFF
#1e90ff
#1E90FF
#GG0000

把它粘进十六进制颜色去重工具,勾选去重,得到的结果是:

#ffffff,出现 3 次,首次出现在第 1 行
#1e90ff,出现 2 次,首次出现在第 4 行
#gg0000,标记为无效,原因是含非十六进制字符

原本六行看着像六种色,规范化去重后真实只有两种有效色,外加一个需要你手工修的无效值。审计表会保留重复次数和首次出现行号,方便你回到原文解释这些重复是从哪份文件混进来的。

统计设计系统实际用了几种色

设计系统精简色板,最怕的就是凭感觉。很多团队的设计 token 文件里挂着几十个颜色变量,但真正在组件里被引用的没那么多,剩下的是历史遗留或临时加的。

去重统计能给你一个硬数字。把所有样式文件、token 清单、甚至从设计稿复制出来的色值合并到一起,跑一遍去重,你就知道这套系统实际落地了几种颜色。重复次数高的,大概率是核心色,值得固化成命名 token;只出现一两次的,往往是该被合并掉的边角色。有了这份清单,精简色板就从"我觉得太多了"变成"实际 47 种里有 38 种可以收敛到 12 种"。如果还想顺手把规范化后的值统一改写,可以接着用十六进制颜色规范化工具批量拉齐写法。

全程本地处理,不上传

颜色值本身不算敏感,但导出文件里常夹着内部命名、项目路径这类信息。我自己整理公司组件库的色板时,直接把整份 token 导出粘进去跑,几千行的文本几秒就出结果,全程在浏览器标签页里完成,没有任何一个字节发到服务器。这点对在内网环境工作的人很重要:不用走审批,也不担心把没发布的设计稿内容泄出去。上传的本地文本文件也是通过浏览器的 File API 在当前页读取,处理完就在内存里,关掉页面就没了。

把这套流程跑顺之后,精简色板这件事就不再靠拍脑袋。先去重看清真实用色,再规范化统一写法,最后收敛成一份干净的 token 清单,每一步都有数据托底。

Made by Toolora · Updated 2026-06-13