三位 hex 不能随意缩写，仅当六位色值为 #aabbcc 形式时才可合法缩为 #abc；浏览器自动双写每位而非近似匹配；八位 hex 不支持三位简写。
三位 hex 能不能随便缩写？看这三条硬规则
不能。#abc 这种三位写法不是“任意六位的简写”，而是有严格条件的：只有当六位值形如 #aabbcc（即红、绿、蓝每组两位完全相同）时，才能合法缩写为 #abc。浏览器会把 #abc 自动展开为 #aabbcc，而不是靠“四舍五入”或“就近匹配”。
-
#ffcc00→ ✅ 可缩为#fc0（因为ff、cc、00各自成对） -
#336699→ ✅ 可缩为#369 -
#ffcc01→ ❌ 不能缩为#fc1（01≠00且 ≠11） -
#123456→ ❌ 无法缩写（12、34、56全部不重复）
三位和六位渲染效果一样吗？精度差异藏在哪
视觉上通常看不出区别，但本质不同：三位 hex 实际只有 4096 种可表示颜色（16³），而六位支持约 1677 万种（256³）。这意味着，如果你从设计稿拿到的是 #1a2b3c，它根本不符合简写条件，强行改成 #123 就会变成 #112233——这是完全不同的颜色，偏灰、偏暗，尤其在浅色或高饱和区域容易露馅。
- 三位简写是语法糖，不是近似压缩
- 所有现代浏览器都按规范解析：三位 → 自动双写每位 → 六位等效值
- 设计师给的色值若含非重复对（如
#e6f7ff），别手欠改#e7f——那会变成#ee77ff，错得离谱
CSS 文件里该用三位还是六位？别省那几个字节
实测：把 #ffffff 改成 #fff 确实省 3 字节，但代价是维护成本陡增。搜索替换时你要同时处理 #fff、#ffffff、white；自动化工具（如 PostCSS、stylelint）可能因格式混用报错；CI 流程里 diff 也更容易产生无意义变更。
- 现代构建工具（Vite、Webpack）默认启用 CSS 压缩，六位自动优化，无需手动缩写
- 团队协作中，统一用六位更可靠——尤其当颜色来自 Figma 插件、设计系统 token 或后端 API 返回时
- 唯一合理用三位的场景：手写极简 demo、内联样式快速调试（如
style="color:#f00"）
八位 hex（带透明度）支持三位简写吗？不支持
CSS 的八位写法 #RRGGBBAA（如 #ff000080 表示半透红）没有三位对应形式。你不能写 #f008 或类似变体——浏览器直接忽略。透明度必须显式写出两位 alpha 值。
立即学习“前端免费学习笔记（深入）”；
- 要实现透明效果，优先用
rgba()或hsla()，语义清晰且支持变量计算 - 如果坚持用 HEX，只能老老实实用八位：如
#0000004D（≈30% 透明黑） - 注意：IE 不支持八位 hex，如需兼容旧环境，必须降级为
rgba()+ filter 回退
真正容易被忽略的点是：三位简写不是“更短就好”，而是“必须精确匹配”。它不像 JS 的隐式转换，错了不会报错，只会静默渲染出另一个颜色——这种 bug 往往上线一周后才被 UI 同学指着说：“这个蓝色怎么比设计稿灰了一截？”
