fc1渲染不出颜色是因为浏览器将其展开为#ffcc11而非目标色#ffcc01，三组不全等导致整条声明被静默丢弃，开发者工具中该行会显示删除线。
#rgb 缩写本身不丢失精度，但“强行缩写”或“误判可缩写性”会导致浏览器静默丢弃整条声明——这不是精度问题，是语法失效。
为什么 #fc1 渲染不出颜色，却没有任何报错
浏览器对 #rgb 的解析极其严格：只有当原始六位值形如 #rrggbb 且每组两位完全相同时（如 #ffcc00 → #fc0），才接受三字符缩写。
写成 #fc1，浏览器会尝试展开为 #ffcc11，但它根本不是你想要的 #ffcc01；更关键的是，只要展开逻辑不匹配（哪怕只有一组不等），整条 CSS 声明就被直接忽略——不报错、不警告、不 fallback。
-
#abc✅ 展开为#aabbcc，合法 -
#ab0✅ 展开为#aabb00，合法 -
#fc1❌ 意图是#ffcc01，但展开得#ffcc11，三组不全等 → 声明被丢弃 -
#f601❌ 长度非法（4 位），直接忽略
开发者工具里怎么一眼看出是不是缩写失效
在 Chrome / Firefox / Edge 的 Elements 面板中定位到该样式行：
如果 color: #fc1 这一行被划掉（strikethrough）且无高亮，说明浏览器已拒绝解析；右键该属性 → “Force element state” 或临时改成 #ffcc01，若颜色立刻出现，就坐实是缩写问题。
- 别依赖肉眼比对：设计稿给的是
#ffcc01，你手敲成#fc1，看起来一样，实则无效 - 构建工具（如 cssnano）默认只压缩合法缩写，不会把
#ffcc01错压成#fc1；但编辑器插件（如 VS Code 的 Color Highlight）可能自动转写，需关掉自动缩写功能 - PostCSS 插件如
postcss-color-hex-minify会校验后再缩，但不处理字符串拼接场景（如 JS 动态生成"#" + r.toString(16) + g.toString(16) + b.toString(16)）
为什么统一用 6 位格式能避开所有坑
#000 和 #000000 数值等价，但某些嵌入式渲染引擎、旧打印机驱动或低功耗 OLED 屏幕对短格式的扩展逻辑不一致；混用时可能在 border + background 交界处暴露亚像素级色差。更重要的是，6 位格式规避了所有语法歧义：
- 长度明确（必须是 3/4/6/8 位），少一位或多一位都静默失效
- 不依赖人眼判断“能不能缩”——
#ff6b6b就是#ff6b6b，不猜、不试、不翻文档 - 团队协作中 Git diff 干净，stylelint 可稳定校验（如
color-hex-length: ["always", "6"]） - CI 构建、小程序 WebView、Electron 旧版等环境对 6 位支持最稳，无兼容性盲区
#fc1 不是颜色变灰了，是压根没生效；而你盯着页面反复调色，却卡在一条早已被浏览器扔进垃圾桶的 CSS 上。 
