CSS变量真正减小体积的关键在于高频复用场景：将重复出现10+次的值（如主题色、间距）抽为全局变量，使原始值仅存一份，var()引用仅占几字节，实测中后台项目gzip后CSS体积可降9–13%。
为什么CSS变量能真正减小体积，而不是“看起来更短”
直接写color: #3b82f6和用--primary: #3b82f6; color: var(--primary)在单处使用时，后者反而略大。真正节省发生在**重复声明场景**：当同一颜色、间距、圆角等在 10+ 个选择器中出现，CSS 变量把“值”抽到一处，所有var()引用只占几个字节，而原始值（如#3b82f6）会被重复写 10 次以上。实测中，中后台项目将 12 个常用色、8 组间距、6 种字体大小转为变量后，gzip 后 CSS 体积下降约 9–13%。
哪些变量该提，哪些不该提——按类型分类处理
盲目提取所有值会适得其反。关键看是否满足「高频复用 + 低变动性」：
-
该提：主题色（
--color-primary）、基础间距（--spacing-xs）、字体层级（--font-size-lg）、圆角基数（--radius-md）——这些在组件库、布局、表单中高频出现，且极少单点修改 -
不该提：仅用 1–2 次的临时值（如某个 Dialog 的
z-index: 9999）、带业务语义的值（如--user-card-bg，它本质是--color-surface的别名，应复用而非新增）、动画关键帧中的具体数值（transform: translateX(42px)）——这类提取后反而增加 indirection，且难维护 -
慎提：响应式断点值（
--breakpoint-md）。若只在@media里用一次，不如直接写(min-width: 768px)；但若多个组件都基于它做 JS 判断或伪类计算，再提不迟
变量作用域混乱是体积反弹的隐形推手
很多人把所有变量塞进:root，结果每个页面哪怕只用一个按钮，也要加载全部 87 个变量定义。更糟的是，CSS Modules 或 Shadow DOM 场景下，:root变量无法被局部覆盖，导致不得不写冗余的!important或更高权重选择器来覆盖，进一步膨胀体积。
正确做法是分层作用域：
- 全局主题变量放
:root（如--color-primary） - 组件级变量放组件根元素（如
.card { --card-padding: 1rem; }），子元素用var(--card-padding)自动继承 - 禁用
!important覆盖变量，改用嵌套作用域优先级（.card.compact { --card-padding: 0.5rem; }） - 避免在
@keyframes或@supports里引用未定义变量——Sass 编译期不会报错，但运行时无效，构建工具也无法 tree-shake 掉整段规则
和 Sass 变量混用时最容易踩的坑
Sass 变量（$primary-color）在编译期求值，CSS 变量（--primary）在运行时生效，二者不能互换。常见错误：
- 在 Sass 中写
background: var(--primary)，以为能 fallback —— 实际上 Sass 不解析var()，它原样输出，浏览器运行时才读取，无法实现降级 - 用 Sass 循环生成 CSS 变量：
@for $i from 1 through 10 { :root { --size-#{$i}: #{$i}rem; } }—— 这会生成 10 行冗余定义，且无法被 PurgeCSS 识别剔除 - 把 CSS 变量当 Sass 函数用，比如试图
calc(var(--spacing-xs) * 2)在 Sass 层计算 —— 必须交给浏览器运行时，Sass 无法提前算出结果 - 变量命名冲突：
$radius和--radius共存，团队新人容易混淆哪处该改，最终两边都维护，造成事实上的双倍体积
真正省体积的关键不在“用了多少变量”，而在“删掉了多少重复值”和“规避了多少作用域污染”。只要变量定义没被实际消费，它就是纯体积负债。上线前用grep -o "var(--.*?)" dist/main.css | sort | uniq -c | sort -nr扫一遍，凡出现次数 ≤ 2 的变量，先问一句：它真有必要存在吗？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
