应使用postcss解析ast提取颜色声明并统计频次，合并语义相同颜色、保留状态色差异，通过语义化变量安全替换，避免误伤非样式内容，并兼顾兼容性与压缩收益。
怎么识别CSS里重复的颜色值
靠肉眼扫一遍 color、background-color、border-color 这些属性，效率低还容易漏。真正靠谱的做法是用工具提取所有颜色声明，再统计频次。
- 用正则
/color\s*:\s*([^;]+);/gi或/background(?:-color)?\s*:\s*([^;]+);/gi匹配，但要注意rgba()、hsl()、变量（如var(--primary)）和注释干扰 - 更稳的方式是解析 AST：用 PostCSS 插件（比如
postcss-color-hex-length或自写插件）遍历所有 Declaration 节点，过滤出prop为颜色相关且value是十六进制/rgb/hsl 字符串的节点 - 注意别把伪类里的颜色（如
a:hover { color: #007bff; }）当成独立重复项——它和普通a { color: #007bff; }是同一处逻辑，应合并统计
哪些颜色值该合并，哪些必须保留
不是所有重复色都要抽成变量。关键看语义是否一致，而不是视觉是否相同。
- 同个 UI 元素不同状态的颜色（如按钮默认
#007bff、悬停#0056b3、禁用#6c757d）不能强行统一成一个变量，哪怕其中两个值碰巧一样 -
#fff和white在 CSS 中等价，但重构时建议统一为#fff（更短、无兼容风险），避免混用 - 带透明度的颜色要小心：
rgba(0,123,255,0.1)和#007bff1a是等价的，但后者在旧版 Safari 不支持，如果项目需兼容 iOS 13 以下，就得保留前者或加回退 - 渐变里的颜色（如
linear-gradient(to right, #007bff, #0056b3)）一般不抽变量，因为改了会影响整个渐变逻辑，维护成本高过收益
用 CSS 自定义属性安全替换的实操要点
直接全局搜索替换 #007bff → var(--primary) 很危险，容易误伤注释、URL、字符串内容里的颜色值。
- 先建变量表：在
:root里集中定义，比如--primary: #007bff;、--text-primary: #212529;，命名反映用途而非色值 - 替换时限定作用域：只改
color:、background-color:等明确的颜色属性值，跳过content: "#007bff";或url("icon-#007bff.svg") - 检查计算值影响：如果某处用了
color: lighten(#007bff, 10%)（Sass），就不能直接换var(--primary)，得改用color-mix()或 HSL 函数，或者干脆保留预编译逻辑 - 验证继承行为：比如
button { --primary: #dc3545; }会覆盖:root的同名变量，但子元素若没显式继承，可能意外回退到旧值
压缩后体积没变小？可能是这些地方拖了后腿
抽变量本身会增加字符数（var(--primary) 比 #007bff 多 8 字节），只有复用足够多次才净节省。
立即学习“前端免费学习笔记（深入）”；
- 统计显示某色值只出现 2–3 次，就别硬抽变量；5 次以上再考虑，10 次以上收益明显
- 确保构建工具没把变量展开：Webpack 的
css-loader默认不解析var()，但如果配了postcss-custom-properties且设preserve: false，会转回原值，白忙一场 - Gzip 对重复字符串敏感，但变量名（如
--primary）如果只用一次，反而增加字典负担；优先压缩高频、长值（如#e9ecef替换为--gray-200） - 别忽略内联样式和 JS 动态插入的 CSS：它们不会响应
:root变量，得同步改逻辑，否则页面出现“一半主题一半裸色”
真正卡住进度的往往不是技术，而是设计系统里没对齐的色值命名习惯——比如设计师给的“主蓝”在 Figma 是 #007bff，而开发文档写的是 #0077bb，这种差异比语法问题更难自动发现。
