css变量本身不慢，但深层选择器匹配、getcomputedstyle读取和calc()嵌套三者叠加会非线性放大样式计算开销；应就近定义变量、避免全局查找、预读计算值并慎用含变量的calc()。
不是CSS变量本身慢，而是它被用在了容易放大样式计算开销的地方——尤其是深层选择器、getComputedStyle读取、calc()嵌套这三类场景叠加时，Recalculate Style时间会非线性飙升。
深层选择器 + var() 触发样式匹配雪崩
浏览器从右往左匹配选择器，而每个var(--color)又要向上遍历祖先找定义。两者一碰，就变成“每个匹配元素都查一遍作用域链”：
-
.modal .header .title { color: var(--text-color); }匹配 500 个.title，平均回溯 3–4 层才能定位变量值 - Chrome Performance 面板里
Recalculate Style占主线程 CPU 40%+，不是因为变量声明，而是匹配+查找+计算全量重跑 - 解决办法：改用 BEM 类名（如
.article__title），把变量定义在就近祖先上（.article { --text-color: #333; }），避免全局:root查找
getComputedStyle 读取 var() 值强制同步布局
JS 里调用 getComputedStyle(el).color 获取依赖变量的值，浏览器必须立刻完成样式计算+layout，不能缓存或延迟：
- 错误写法：
for (let el of list) { getComputedStyle(el).color; }—— 每次循环都卡住主线程 - 正确做法：提前读取
getComputedStyle(document.documentElement).getPropertyValue('--size')，复用结果；或用requestAnimationFrame节流 - 注意：
el.style.setProperty('--x', 'y')是异步的，但紧跟着getComputedStyle就会触发强制 layout
calc(var(--spacing) * 2) 让引擎失去静态优化
calc(16px + 8px) 可被提前折叠，但含 var() 的 calc() 必须运行时解析、查找、计算，且无法缓存中间结果：
- 实测：1000 个元素用
width: calc(var(--base) * 1.5)，比用预设width: var(--base-wide)多出 12–18ms 样式计算 - 更隐蔽的是：改一个
:root上的--spacing，所有含该calc()的规则都会被标记为“需重算”，触发全量而非局部更新 - 高频动画中应避开
transform或opacity里混用var()+calc()；优先用 JS 预算后写入style.transform
真正决定性能的，从来不是你写了多少个 --color，而是它被多少节点读、在什么选择器里用、有没有和 calc() 或布局属性绑在一起——这些组合才是隐性卡点，容易在上线后才暴露。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
