CSS变量本身不慢，但深层DOM中读取var()会显著拖慢getComputedStyle：深度≥6层时耗时翻倍，深度12层时低端机单次调用卡顿超80ms；calc(var(--x)*2)失去静态优化，每次重绘都需运行时解析；循环中setProperty后紧接getComputedStyle会强制同步计算，引发layout thrashing。
不大，但容易在特定组合下被放大成明显卡顿——不是变量本身慢，而是你“怎么用”“在哪用”“用多少次”共同决定实际开销。
深层 DOM 中读取 var() 会显著拖慢 getComputedStyle
DOM 深度 ≥6 层时，getComputedStyle(el).getPropertyValue('--x') 耗时会翻倍；深度达 12 层，低端机单次调用可能卡住主线程超 80ms。浏览器必须沿祖先链逐层回溯找定义，每深一层就多一次查找。
- 实测现象：
document.querySelector('.deep .nested .item')返回的元素若嵌套在 7 层 div 内，调用getComputedStyle会触发长任务，Performance 面板里Recalculate Style时间陡增 - 排查方法：控制台运行脚本扫描深度 ≥6 的节点，或右键 Elements 面板节点 → “Show DOM properties” 查
node.depth - 解决方向：把变量定义在更靠近目标元素的祖先上（比如
.card { --color: #333; }），而非全挂:root
calc(var(--x) * 2) 会让样式引擎失去静态优化
纯数字 calc(16px + 8px) 可被浏览器提前折叠，但 calc(var(--spacing) * 2) 必须保留运行时计算逻辑，无法缓存、无法合并，每次重绘都重新解析+查找+运算。
- 影响范围：该规则命中 1000 个元素时，样式计算比预设
--spacing-wide: 32px多出约 12–18ms - 连锁反应：改一次
:root上的--spacing，所有含calc(var(--spacing) * )的规则都会被标记为需重算，触发全量而非局部更新 - 替代方案：对高频动画或滚动场景，优先用 JS 预算好值后直接写
el.style.width = '32px'，或用transform+will-change升层
批量 setProperty('--x', val) 没问题，但紧接 getComputedStyle 就卡
el.style.setProperty('--color', 'red') 本身不触发重排，是惰性更新；但一旦后面立刻跟 getComputedStyle(el).color，浏览器必须同步完成样式计算+布局，变成强制回流。
立即学习“前端免费学习笔记（深入）”；
- 典型错误：
for (let el of list) { el.style.setProperty('--size', i + 'px'); const c = getComputedStyle(el).color; }→ 每轮都卡住主线程 - 正确做法：先批量设置变量，再统一读取原始
el.style.cssText或dataset；或用requestAnimationFrame节流读取 - 注意：
document.documentElement.style.setProperty()看似全局，实则让所有依赖该变量的元素都参与重算，局部变量请直接操作目标元素el.style.setProperty()
真正容易被忽略的是：CSS 变量的性能优势只在「高频动态更新」场景下才明显；初始化设一次，和直接写内联样式几乎没差别。而一旦叠加深层选择器、嵌套 calc、循环读取三者中的两个，开销就会非线性增长——不是渐进变慢，而是某天突然卡住滚动或动画。
