只有当#rrggbb中每组两位十六进制数完全相同（如#ff6600→#f60）时才可安全缩写为#rgb；否则浏览器直接忽略该声明。
哪些#rrggbb能安全缩写成#rgb
只有当每组两位十六进制数完全相同时，才能缩写——比如 #ff6600 可以缩成 #f60，但 #fe6601 不行，因为 fe ≠ ff、66 = 66、01 ≠ 00，三组必须全部满足“两位相同”才合法。
浏览器解析时会严格校验：不合规的简写（如 #f601 或 #fg0）直接忽略整条声明，不会 fallback 到默认色或报错提示。
-
#000✅ 等价于#000000 -
#abc✅ 等价于#aabbcc -
#ab0✅ 等价于#aabb00 -
#ab01❌ 非法长度，被丢弃 -
#a0c✅ 但等价于#aa00cc，不是#a000cc
CSS里写#rgb时要注意的兼容性细节
所有现代浏览器（Chrome 1+、Firefox 1+、Safari 1+、Edge 12+）都支持 #rgb 和 #rgba（后者是带 alpha 的四字符形式），但老版本 IE（≤8）只认六位写法，#f60 在 IE8 及更早版本中会被当作无效值处理，回退为继承色或透明背景。
如果你的项目还需兼容 IE8，就别用简写——这不是“推荐不推荐”的问题，是“写了等于没写”的实际失效。
立即学习“前端免费学习笔记（深入）”；
- IE9+ 支持
#rgb和#rgba -
#rgba（如#f608）是 CSS3 新增，IE9 不支持，需 IE10+ - PostCSS 或构建工具（如 Autoprefixer）默认不转换颜色简写，它不认为这是兼容性问题
自动转换工具和编辑器行为差异
VS Code、WebStorm 等编辑器在保存时可能自动把 #aabbcc 转成 #abc，但这个行为依赖插件（如 “Auto Rename Tag” 不管这事，“Color Highlight” 也不改写），且通常只对纯色生效，不碰变量或 CSS-in-JS 字符串里的值。
真正可靠的自动化发生在构建环节：比如用 postcss-color-hex-alpha 处理 #rrggbbaa，或用 cssnano 的 reduceColor 选项压缩颜色——但它默认开启，且只缩写合法的六位色，不会乱改 #123456。
- 手动替换风险高：
sed -i 's/#\([0-9a-f]\)\1\([0-9a-f]\)\2\([0-9a-f]\)\3/#\1\2\3/gi'这类正则容易误伤注释或字符串 - SCSS/LESS 中的
#fff是字面量，编译后仍是#fff，不展开也不压缩 - JavaScript 动态设置
element.style.backgroundColor = '#f60'完全合法，和 CSS 文件中写法无区别
为什么有些设计系统坚持不用#rgb简写
不是技术不行，是维护成本和可读性权衡的结果。比如 Figma 导出的 CSS、Ant Design 的 token 文件、或者团队约定“所有颜色统一六位”，目的都是避免人眼快速分辨时出错：#112233 和 #123 看起来像不同色，但其实一样；而 #123 和 #112233 并排出现时，前者容易被当成笔误。
另外，自动化颜色对比工具（如 axe、Lighthouse）内部通常标准化为 RGB 十进制计算对比度，输入 #123 和 #112233 结果一致，但团队协作中“写死六位”能减少 code review 时的质疑点。
- CI 流程里加校验（如 stylelint 的
color-hex-length规则）可以强制统一格式 - 简写在压缩率上几乎无收益：gzip 后
#f60比#ff6600少 3 字节，实际影响可忽略 - 最易被忽略的一点：CSS 自定义属性里写
--main-bg: #f60，后续用var(--main-bg)是完全 OK 的，但若某处误写成--main-bg: #f6（少一位），整个变量就无效了
