PostCSS 8.4以下版本不支持#RRGGBBAA，旧版解析器会报错或静默丢弃整条声明，导致样式失效；需升级PostCSS至8.4+、cssnano至v5.1+并启用level4支持，或用postcss-color-hex-alpha插件降级为rgba()。
PostCSS 8.4 以下版本不识别 #RRGGBBAA 语法
很多项目还在用较老的 PostCSS（比如 8.3 或更早），而 #RRGGBBAA 是 CSS Color Module Level 4 的特性，直到 PostCSS 8.4 才原生支持。旧版解析器遇到八位写法会直接报错或静默丢弃整条声明，导致样式失效且无提示。
常见现象包括：
- 构建时报
Unknown word或Invalid CSS after错误，定位到某行background-color: #0b79b966; - 样式正常编译但浏览器里颜色变黑/透明/继承默认色——其实是被插件跳过了
- 启用
postcss-preset-env时未配置stage: 4，它默认只处理 stage 3 及以下特性
cssnano 默认压缩策略会删掉八位 HEX
cssnano 在 v5.0 之前（尤其搭配 autoprefixer 旧版使用时）会把不认识的值当成无效语法直接剔除，#0b79b966 就可能被清空成 background-color: ;，最终回退到父级颜色或初始值。
这不是 bug，是“安全优先”策略：宁可删掉，也不留风险语法。解决方式只有两个：
立即学习“前端免费学习笔记（深入）”；
- 升级
cssnano到 v5.1+，并确认其compatibility配置开启level4支持 - 在构建前用
postcss-color-hex-alpha插件提前降级为rgba()，例如把#0b79b966转成rgba(11, 121, 185, 0.4)
Webpack 4 + css-loader 3.x 对八位 HEX 解析不稳定
Webpack 4 默认集成的 css-loader@3.x 内部用的是较老的 postcss 实例，即使你项目里装了新版 PostCSS，它也可能走自己的私有副本。结果就是：开发服务器能渲染，但 npm run build 出的生产包里颜色全没了。
验证方法很简单：
- 临时把
background-color: #0b79b966;改成background-color: rgba(11, 121, 185, 0.4);，再构建看是否恢复 - 检查
node_modules/css-loader/package.json中的peerDependencies，若写着"postcss": "^7.0.0"，基本就踩中了 - 升级路径：Webpack 4 → 升
css-loader到 v6+；Webpack 5 → 默认支持，但仍需确认postcss-loader版本 ≥ 6.2
CI/CD 环境 Node 版本太低触发解析失败
某些 CI 流水线还跑在 Node 14 上，而新版 PostCSS（≥ 8.4）要求 Node ≥ 16.10。Node 14 下即使写了 "postcss": "^8.4.0"，npm install 也可能自动降级到兼容版（如 8.3.x），导致八位 HEX 在构建机上被拒。
这不是配置问题，是依赖树实际解析结果。排查时别只看 package-lock.json 顶层版本，要搜整个文件里 postcss 出现的所有位置，尤其是嵌套在 postcss-preset-env 或 cssnano 下的子依赖。
真正容易被忽略的是：八位 HEX 看似只是多两位字符，但它撬动的是整条构建链路对 CSS 新标准的支持水位。一个没显式声明的 peerDependencies、一次隐式降级、甚至 CI 镜像里的 Node 缓存，都可能让颜色在上线前最后一刻消失。
