浏览器将#rgb确定性展开为#rrggbb，每位字符复制一次，如#f0a→#ff00aa、#abc→#aabbcc；仅当原六位值每组两位完全相同时才可安全缩写，否则声明失效。
3位和6位hex颜色显示一致，是因为浏览器在解析时把#rgb确定性地展开成了#rrggbb，不是“看起来差不多”，而是计算值完全相同。
浏览器怎么展开#rgb？
所有现代浏览器（Chrome、Firefox、Safari、Edge）都按同一规则处理：每个字符复制一次。#f0a → #ff00aa，#abc → #aabbcc。这个过程发生在样式解析阶段，早于布局和绘制，不依赖运行时环境或设备。
关键点：
-
#fff展开为#ffffff（R=G=B=255），不是#f0f0f0或#fa0 - 展开是单向的、无损的，且不可逆——
getComputedStyle(el).color返回的永远是rgb(255, 255, 255)，原始写法信息丢失 - 没有浏览器把
#999当成#909090，这种误解纯属人工误读
哪些3位写法是安全的？
只有当六位原值中每组两位完全相等时，才能缩写。这不是“能省就省”，而是“必须满足条件才合法”。
- ✅
#ff6600→ 可缩为#f60（因为ff、66、00各自成对） - ✅
#aabbcc→ 可缩为#abc - ❌
#fe0123不可缩——fe≠ff或ee，01≠00或11，强行写成#fe1会变成#ffe111，色值彻底错乱 - ❌
#8b4513（巧克力棕）不能简成#8b4——b≠4，4≠1，直接失效
为什么有时候看着不一样？
显示差异从来不是解析导致的，而是渲染链下游的问题：
- 元素叠加了
filter: contrast()或backdrop-filter，但只加在其中一个上 - 一个元素启用了
will-change，另一个没启用，导致 GPU 图层合成路径不同，受 HDR 或 OLED 低亮度偏色影响程度不一 - 用取色器点选的位置落在抗锯齿边缘、subpixel 渲染区或文本阴影重叠区
- 系统开启了“原彩显示”，但该调整作用于最终输出管线，不影响 CSS 计算值本身
真正容易被忽略的是：缩写合法 ≠ 语义清晰。你在 Git diff 里看不出 #333 和 #333333 的区别，但前者是简写，后者是完整值；自动化工具读取的是计算后颜色，而人眼比对时却要 mentally 展开——这中间的 gap，往往在 Code Review 或设计验收时才暴露出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
