颜色深度优化关键在减少冗余声明而非缩写写法，应通过css自定义属性统一语义化管理颜色，禁用硬编码值，避免currentcolor隐式膨胀，并依靠工程化规范而非postcss自动合并。
为什么 color 声明多不等于颜色“深”
很多人看到“颜色深度优化”第一反应是压缩十六进制值（比如把 #ff0000 缩成 #f00），但实际影响样式表体积的，是重复声明本身，不是写法长短。浏览器解析 color 时对 #f00 和 #ff0000 的处理成本几乎一样，真正拖慢加载的是冗余规则数量。
- 每多一条
color: #333，就多一个 CSS Token、一次属性匹配、一次继承计算 - 在组件化项目里，
color往往被散落在几十个.scss文件中，同一语义色（如“正文文字”）可能有 5 种写法：#333、rgb(51, 51, 51)、var(--text-primary)、inherit、甚至unset - 构建工具（如 PostCSS）通常不合并跨选择器的
color声明，哪怕值完全相同
用 CSS 自定义属性统一管理颜色语义
把颜色从“值”升级为“含义”，才能真正减少声明次数。关键不是删代码，而是让一次定义覆盖所有使用点。
- 在
:root中只定义语义变量，例如：--color-text-primary: #1a1a1a，不定义--color-red-500这类无上下文的原子变量 - 业务组件中统一用
color: var(--color-text-primary)，禁用任何硬编码值（包括currentColor以外的字面量） - 如果需要主题切换，直接替换
:root下的变量值，不用改任何组件样式 - 注意：sass/less 的
$text-color变量不能替代 CSS 自定义属性——它在编译期展开，无法运行时切换，也不参与 CSSOM 树的复用优化
警惕 currentColor 的隐式膨胀陷阱
currentColor 看似省事，但它会让颜色继承关系变得不可控，反而增加渲染路径复杂度。
- 当父元素频繁变更
color（比如导航菜单 hover 时），子元素用currentColor会触发重绘，且浏览器无法提前判断是否需重排 - 在 SVG 内联样式中滥用
currentColor（如fill="currentColor"）会导致图标颜色强耦合文本色，一旦设计稿要求图标独立配色，就得加额外 class 覆盖 - 更稳妥的做法：给图标等装饰性元素单独定义语义变量，例如
--icon-fill: var(--color-icon-default)，显式可控
PostCSS 插件能自动合并吗？别依赖
像 postcss-merge-longhand 或 cssnano 的默认配置，对 color 几乎不合并——因为 CSS 规则优先级、继承链、媒体查询上下文会让“值相同=可合并”变成高危操作。
立即学习“前端免费学习笔记（深入）”；
-
color是继承属性，.a { color: red } .b { color: red }不能简单合并为.a, .b { color: red }，除非确认二者无嵌套、无不同祖先色、无 js 动态修改 - 某些插件开启
mergeLonghand: true后，反而会把原本可缓存的原子规则打散，降低 CSSOM 复用率 - 真正有效的压缩发生在构建前：用 ESLint + stylelint 规则拦截硬编码色值，例如
stylelint-config-standard配合declaration-Property-value-disallowed-list禁用#开头的值
颜色优化的难点不在技术手段，而在于团队能否守住“语义 > 字面量”的边界。一旦某个组件偷偷写了个 color: #222，后续所有自动化都得绕着它打补丁。