当颜色需跨组件、主题或状态复用且可能调整时，应使用 CSS 自定义属性；硬编码会导致维护困难。适用主色、语义色等，禁用临时调试色。需分层管理、语义命名，深色模式下注意伪类覆盖与作用域层级。
什么时候该用 CSS 自定义属性（--color-primary）而不是写死 #007bff
当一个颜色在多个组件、主题或状态中重复出现，且未来可能调整（比如换肤、适配深色模式、品牌升级），就必须抽成 CSS 自定义属性。硬编码颜色值会让全局替换变成全文本搜索+逐个确认，极易漏改或误改。
- 适用场景：主色、辅色、文本灰阶、边框色、禁用态背景等有语义的颜色
- 不适用场景：某个按钮的临时调试色、一次性装饰性渐变中的某段色值、CSS 动画关键帧里需要精确控制的中间色
- 命名要带语义，比如
--color-brand-blue比--color-blue-500更利于维护——后者隐含了设计系统层级，但一旦设计系统升级，-500含义可能漂移
var(--color-primary) 和直接写 rgb(0, 123, 255) 的性能与兼容性差异
CSS 自定义属性本身不触发重排重绘，解析开销可忽略；真正影响性能的是大量嵌套 var() + calc() + fallback 组合，尤其在动画关键路径上。IE 完全不支持自定义属性，如需兼容 IE，必须提供降级方案。
- 现代浏览器（Chrome 49+、Firefox 31+、Safari 9.1+）对
var()解析非常高效 - 不要在
@keyframes中用未声明的var()，它不会回退到 fallback，而是直接失效 - fallback 只在变量未定义时生效，不是类型校验：写成
color: var(--text-color, #333);是安全的；但color: var(--text-color, 20px);会导致该声明整个无效
如何组织颜色变量才能避免“变量爆炸”和“语义污染”
把所有颜色塞进 :root 会导致命名冲突、查找困难、无意义的复用。应分层管理：基础色（brand）、语义色（text、border、background）、状态色（hover、disabled）。
- 基础色只存原始品牌值，例如
--color-brand-blue: #007bff;，不存衍生色（如--color-brand-blue-light） - 语义色通过
calc()或color-mix()（较新）动态生成，比如--color-text-primary: color-mix(in srgb, var(--color-brand-blue) 87%, black); - 避免为每个组件单独建颜色变量（如
--header-bg、--card-border），除非该色值确有独立设计意图且跨主题变化
深色模式下颜色变量切换的实际陷阱
仅靠 @media (prefers-color-scheme: dark) 覆盖 :root 变量是常见做法，但容易忽略继承链断裂和伪类样式覆盖问题。
立即学习“前端免费学习笔记（深入）”；
- 确保所有用到颜色的地方都用了
var()，否则深色模式下部分元素仍显示亮色 -
:hover、:focus等伪类里的颜色必须显式声明，不能依赖父级继承 —— 浏览器不会自动把var(--color-hover)套到伪类里 - 不要在 JS 中读取
getComputedStyle后再设内联色值，这会切断 CSS 变量响应链；应通过切换 class（如theme-dark）来驱动变量更新
:root {
--color-bg: #ffffff;
--color-text: #333333;
}
@media (prefers-color-scheme: dark) {
:root {
--color-bg: #1a1a1a;
--color-text: #e0e0e0;
}
}
body {
background-color: var(--color-bg);
color: var(--color-text);
}
最易被忽略的一点：颜色变量的 scope 不是“页面级”，而是“匹配选择器的作用域”。如果在某个组件内部重新定义了 --color-text，它不会影响其他组件，但也意味着你无法靠一次修改统一整站文字色——必须确保变量定义位置合理，且层级足够高。
