CSS变量是带作用域的命名空间，非语法糖；应统一定义、语义化命名、禁嵌套引用、慎用calc运算、加命名空间防覆盖，并纳入CI校验与生命周期管理。
用 --color-primary 而不是 #007bff 直接写死
硬编码颜色值会让样式表变成“猜谜游戏”：改一个 #007bff，你得翻三处确认它到底是不是主色；换主题时更得全文本搜索替换，漏一个就错位。CSS 变量本质是命名空间+作用域控制，不是语法糖。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有颜色、间距、圆角、阴影强度都抽成变量，命名带语义前缀，比如
--space-md、--radius-sm、--shadow-card - 变量定义统一放在
:root或独立的_variables.css文件里，避免散落在组件中 - 禁止在变量值里嵌套另一个变量（如
--color-error: var(--color-red-500)），CSS 不支持运行时求值，会退化成字面量，后期维护反而更难追溯 - 深色模式切换靠媒体查询 + 变量重定义，而不是写两套类名，例如：
:root { --color-bg: #fff; }<br>@media (prefers-color-scheme: dark) {<br> :root { --color-bg: #1e1e1e; }<br>}
var(--font-size-base) 的 fallback 不能只写 16px
很多人加 fallback 是为了“保底”，但只写 var(--font-size-base, 16px) 在变量未定义时确实能兜住，问题在于——它掩盖了定义缺失这个事实。调试时发现文字突然变小，查半天才发现是某个 scope 里漏了变量注入。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 开发阶段把 fallback 设成明显异常值，比如
var(--font-size-base, 999px)，页面一加载就暴露问题 - 构建时用 PostCSS 插件自动校验变量引用是否都有定义，比 runtime 靠谱
- 组件级变量（如
.card { --card-padding: 1rem; }）必须和组件样式紧耦合，别指望全局变量覆盖一切 - 不要用 JS 动态 setProperty 写大量变量，尤其是高频更新的（如滚动视差），会强制重排
为什么 calc(var(--space-md) * 2) 有时不生效
CSS 变量本身是字符串，calc() 里做运算的前提是变量值已解析为带单位的合法数值。如果 --space-md 定义成 "1rem"（带引号）或 1rem !important，calc() 就直接报错，整条声明失效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 变量值不加引号，不带
!important，单位写全（1rem，不是1） - 乘除运算只支持数字 × 数字 或 数字 × 带单位值，不能
var(--gap) * var(--multiplier)—— 后者必须是纯数字变量，如--multiplier: 2 - 层级嵌套计算要小心：父元素变量被子元素重定义后，子元素内
calc()用的是新值，不是原始值 - IE 完全不支持 CSS 变量，如果还要兼容，得用 Sass/Less 编译后输出静态值，别幻想 runtime 降级
组件库中如何避免 --button-bg 被意外覆盖
变量没有选择器优先级，只有定义顺序起作用。一个第三方 UI 库在 :root 定义了 --button-bg，你项目里也在 :root 改它，谁在后面谁赢——但没人能保证打包顺序稳定，尤其用了 CSS-in-JS 或动态 import。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给变量加命名空间，比如
--myapp-button-bg、--vendor-button-bg，别省那几个字符 - 用
@layer控制层叠顺序（Chrome 110+），把基础变量放@layer base，覆盖逻辑放@layer theme - 组件内部用
element.style.setProperty()设置变量时，务必检查是否已有同名变量，否则可能污染全局 - CI 流程里加一条检查：grep 所有
var(--.*-bg)，确保每个都对应一个定义，漏定义就 fail 构建
变量命名一旦定下来，改起来比改 JS 函数还疼——因为样式没类型检查，也没引用追踪。最常被忽略的是变量生命周期管理：谁定义、谁使用、谁清理。别等出了线上 bug 才发现 --legacy-spacing 还活在五个文件里。
