CSS变量性能瓶颈源于样式计算开销非线性增长：深层选择器叠加var()导致匹配雪崩，getComputedStyle强制同步布局，calc()嵌套var()丧失静态优化且触发全量重算。
var() 本身不触发重排，但大规模 DOM 下性能下降，根本原因是样式计算（Recalculate Style）开销呈非线性增长——不是变量本身慢，而是浏览器匹配 + 查找 + 计算的链路被放大。
深层选择器 + CSS变量 = 样式匹配雪崩
浏览器从右往左解析选择器，而var(--color) 又需向上遍历作用域链找定义。两者叠加时，每个匹配到的元素都要做两次昂贵操作：
- 回溯祖先节点找最近的
:root或带--color的祖先元素 - 对每个匹配结果重新走一遍样式继承与计算逻辑
.modal .header .title { color: var(--text-color); }，页面有 500 个 .title，平均要向上查 3–4 层才能定位变量值，Chrome Performance 面板里会看到「Recalculate Style」时间陡增，甚至占主线程 CPU 40% 以上。
getComputedStyle 读取变量值会强制同步布局
JavaScript 里调用getComputedStyle(el).color 获取一个依赖 var() 的值，浏览器必须立刻完成：
- 完整样式计算（包括所有
var()替换） - 同步执行 layout（强制回流）
for (let el of list) {
const c = getComputedStyle(el).color; // 每次都卡住主线程
}
正确做法：先批量读取原始 style 或 dataset，或用 requestAnimationFrame 节流；避免在循环中混用 el.style.setProperty('--x', 'y') 和紧跟着的 getComputedStyle。
calc() 嵌套 var() 失去静态优化机会
纯数字calc(16px + 8px) 可被引擎提前折叠，但 calc(var(--spacing) * 2) 必须保留运行时计算：
- 无法缓存中间结果
- 每次重绘都要重新解析、查找变量、执行计算
- 若该规则命中上千个元素，开销直接翻倍
:root 上的 --spacing，所有含 calc(var(--spacing) * ...) 的规则都会被标记为“需重算”，触发全量样式更新，而非局部。
真正卡住你的，往往不是变量声明本身，而是变量被“在哪里用”“怎么用”“被多少节点用”这三个条件共同决定的。大规模场景下，var() 的便利性很容易掩盖它对样式引擎的隐性压力。
