十六进制3位颜色缩写错误（如#fc1）会导致color声明被浏览器静默丢弃，文字显示为继承色或默认色；仅当每位字符重复后能精确还原六位值（如#000、#faf）才合法，其余须用六位格式。
十六进制颜色写错最常导致文字“消失”，不是因为透明，而是浏览器静默丢弃整条 color 声明——你看到的是继承色或默认色，控制台却毫无提示。
为什么 color: #fc1 会让文字变“不可见”
这不是透明度问题，也不是颜色太浅。当你写 color: #fc1 想表达 #ffcc01（亮黄），浏览器实际按规则展开为 #ffcc11。但如果你本意是 #ffcc01，那 #fc1 就是错的缩写——CSS 解析器发现它无法无歧义映射回合法六位值，直接跳过该声明，color 属性不生效，文字退回到父级颜色或浏览器默认（通常是黑色或深灰）。这种失效完全静默：无报错、无 warning、Elements 面板里该行被划掉但不标红。
用开发者工具三步定位是否为缩写失效
在 Chrome / Edge / Firefox 的 Elements 面板中：
- 选中文字所在元素，找到对应
color声明（如color: #fc1） - 观察该行是否被划掉（strikethrough）且无高亮背景——这是解析失败的明确信号
- 右键该属性 → “Edit as HTML” 或直接双击修改为六位格式（如改成
color: #ffcc01），看文字是否立刻恢复颜色
若恢复，即可确认是缩写合法性问题。注意：不要只改值，要改完整声明；临时加 !important 无效，因为问题出在解析阶段，而非优先级。
立即学习“前端免费学习笔记（深入）”；
哪些 #RGB 缩写根本不能用
合法缩写必须满足：每位字符重复一次后能精确还原原始六位值。以下全是典型错误：
-
#fc1→ 展开为#ffcc11，≠#ffcc01（你想要的亮黄） -
#a1b→ 展开为#aa11bb，但设计稿给的是#a100bb？根本对不上 -
#fff0（4位）→ 浏览器不识别，直接丢弃；CSS 只认 3/6/8 位，4 位非法 -
#12345（5位）→ 同样非法，静默忽略
真正安全的缩写只有：所有通道值本身是双同字符，例如 #faf（= #ffaaff）、#000（= #000000）、#369（= #336699）。其余一律用六位。
工程中防御性校验建议
靠人眼判断缩写太危险，尤其从 Figma/Sketch 复制或后端返回色值时。可在构建流程或 CI 中加入轻量检查：
- 用
stylelint+color-no-invalid-hex规则，它会捕获#fc1这类无效缩写 - 前端运行时校验（如初始化时）：
function isValidHex3(str) {<br> if (!str || str.length !== 4 || !str.startsWith('#')) return false;<br> const [r, g, b] = str.slice(1);<br> return /^[0-9a-fA-F]$/.test(r) && /^[0-9a-fA-F]$/.test(g) && /^[0-9a-fA-F]$/.test(b);<br>}<br>// 注意：这仅校验字符合法性，不保证语义等价；真要等价需比对展开后字符串 - 团队规范强制：所有提交代码中
color值禁用 3 位缩写，统一走 6 位（stylelint-color-hex-length: "long"）
最易被忽略的点：缩写失效不报错，但它的后果是“文字突然没了”，而你第一反应永远是去查 z-index、opacity 或字体加载——其实该先盯住那串带 # 的值，看它有没有被划掉。
