该用 #fff 而不是 #ffffff 时，仅限纯灰阶且每位重复（如 #112233→#123），#fff 是安全缩写；#ff6600 缩为 #f60 虽合法但降低可读性，旧工具可能警告。
什么时候该用 #fff 而不是 #ffffff
当颜色是纯灰阶（#000、#333、#fff 等）或重复双位十六进制时，浏览器支持缩写。不是所有六位色都能缩，比如 #123456 不能缩成 #123456 → #123 是错的，只有 #112233 才能缩为 #123。
常见错误现象：color: #ff6600; 被硬缩成 #f60 —— 这看似省了 3 字符，但实际语义丢失：原意是 #ff6600（橙红），缩写后变成 #f60（等价于 #ff6600 ✅），可读性下降，且某些旧版编辑器/校验工具会报 warning。
-
#000、#333、#666、#999、#fff安全缩写，无兼容性问题 -
#aabbcc→#abc合法；#ab12cd→#ab12cd不可缩 - PostCSS 或构建工具（如 cssnano）默认开启缩写，但需确认其配置未误伤透明度（
rgba()不参与此缩写）
CSS 中哪些颜色名真能省体积？
标准 CSS 颜色名（如 red、transparent）确实比十六进制短，但仅限于 140 个 W3C 命名色。别信“darkslategray 比 #2f4f4f 短”——它其实多 3 字符。
使用场景：适合高频复用的基础色（black、white、transparent、currentcolor），尤其是 transparent（7 字符）比 rgba(0,0,0,0)（13 字符）或 #0000（不合法）更稳。
立即学习“前端免费学习笔记（深入）”；
- 真正省体积的颜色名只有：
transparent、currentColor、inherit、initial、unset（这些是关键字，非“颜色名”但常被归入） -
red（3 字符）比#f00（4 字符）略优，但语义模糊（不同浏览器渲染略有差异，#f00更精确） - 避免用
lightcoral、mediumseagreen等长名——它们比对应十六进制还长，且不易维护
构建流程里自动优化颜色代码的靠谱方式
手动替换容易漏、易出错，尤其在多人协作或主题色频繁变更时。靠人眼判断 #1a1a1a 能否缩成 #111 是低效的。
性能影响极小，但压缩率真实：一个含 200 处颜色声明的 CSS 文件，合理缩写 + 关键字替换可减少 0.8–1.2KB（Gzip 后约 200–400B）。对首屏关键 CSS 有意义。
- 推荐用
cssnano（配合 PostCSS），开reduceInitial和normalizeWhitespace即可自动处理缩写和关键字替换 - 禁用
convertValues中的 color 相关转换，它可能把#f00强转成red，带来渲染偏差 - 若用 Tailwind，确保
content配置正确，否则text-red-500类中内联的#ef4444可能被遗漏压缩
别忽略 alpha 通道带来的陷阱
hsla()、rgba()、八位十六进制（#rrggbbaa）没法缩写，而且 #ff000080（半透红）不能写成 #f008 —— 浏览器不认这个语法，会直接丢弃整条声明。
容易踩的坑：有人把 background: rgba(255, 0, 0, 0.5); 改成 background: #f008;，结果背景消失。这不是简写，是无效值。
- 八位十六进制（
#rrggbbaa）只在现代浏览器支持（Chrome 65+、Firefox 49+、Safari 12+），IE 完全不支持 - 需要透明色时，优先用
rgba()（兼容性更好）或hsla()（更适合主题系统），而非冒险用八位缩写 - 构建工具如 cssnano 默认不处理
rgba()→hsla()转换，这类转换反而可能增大体积或引入精度误差
#000 替换成 black，而在整套流程是否稳定识别可缩场景、避开 alpha 和命名色陷阱。 
