0.659432→0.659：CSS颜色精度骗局被我扒了

「3位小数就够了，多写一个字节都是浪费。」——这是csskit作者的原话。他花了几个月时间，就为了搞清楚一个看似无聊的问题：CSS颜色值到底要精确到几位？

答案可能会让你删掉一堆代码。

「肉眼不可见」的精度陷阱

先看一个真实案例。作者收到颜色选择器给出的值：oklch(0.659432 0.304219 234.75238)。

小数点后5位、6位、甚至8位。看起来很专业，对吧？

问题是：没有任何人眼能看出区别。作者用CIE2000色差公式（dE00）反复验证，结论是3位小数是安全上限。对于oklch和oklab，写到oklch(.659 .304 234.752)就够了。

更激进的方案：lab()和lch()因为色域范围更大，1位小数就能过关；rgb()、hsl()这种sRGB格式，整数都够用。

作者的原话很直接：「Writing more is just wasting bytes.」

为什么开发者会掉进这个坑

这不是技术问题，是工具惯性。

现代设计工具（Figma、Sketch、Chrome DevTools）为了显示「专业感」，默认输出超高精度。开发者复制粘贴时，连带着把无意义的精度一起搬进代码库。

作者建了一个minifier测试套件，结果发现csskit自己的通过率最差——这反而成了他深入研究的动机。不是要做最炫的工具，是要做最对的工具。

他提到一个关键场景：color-mix()和相对颜色语法。很多人担心精度不够会导致链式计算误差累积。实测证明，3位小数在数学上完全hold住。

「The exceptions to this are so edge case they're irrelevant.」

minifier的隐藏战场

这件事真正的价值在构建环节。

作者的观点很明确：手工调颜色的人，纠结第4位小数纯属浪费时间；写minifier的人，这才是核心优化点。他给出的压缩策略分层很细——

oklch/oklab → 3位小数
lab/lch → 1位小数
rgb/hsl/度数 → 0位小数

每一层都对应人眼感知阈值和色彩空间的数学特性。不是拍脑袋，是用dE00公式量出来的。

CIE（国际照明委员会）搞出的这个色差算法，0.0表示完全一致，100.0是黑白对比。工业界的经验值：dE00 < 2.0时，训练有素的观察者也难辨差异。

作者把阈值压得更狠，直接按字节收益来裁。

「Or don't. I'm not your dad.」

这是全文最妙的一句。作者说完技术结论，立刻补了这句——你可以不听，但minifier应该帮你自动处理。

这种态度很开发者：不给道德压力，只给技术方案。你的代码冗余是你的选择，但工具链有责任做正确的事。

他花大篇幅写验证过程，从CIE76到CIE2000的演进，从ΔE符号的偷懒写法到delta_e的函数命名。细节控到有点可爱。

但核心信息就一句：信任3位小数，或者自己算一遍。

csskit现在还在测试套件里垫底，但作者显然不在乎面子工程。他在建的是一套行业基准——让所有人用同一套精度规则，减少无意义的差异。

下次你从设计稿复制颜色值时，会手动四舍五入吗？还是等着minifier帮你擦屁股？