CSS变量性能开销不大，但深层DOM中读取var()会触发祖先链逐层回溯，深度≥6层时getComputedStyle耗时翻倍，12层时低端机单次调用或卡顿超80ms；calc(var()×n)失去静态优化，每次重绘均需运行时解析；setProperty后紧接getComputedStyle会强制同步计算，引发layout thrashing。
深层DOM中读取var()会触发祖先链逐层回溯
浏览器解析 var(--x) 不是查哈希表，而是运行时沿父节点向上找定义。DOM深度≥6层时，getComputedStyle(el).getPropertyValue('--x') 耗时翻倍；深度达12层，低端机单次调用可能卡住主线程超80ms。这不是“慢一点”，而是直接变成长任务，Performance面板里Recalculate Style时间陡增。
常见错误现象：
-
document.querySelector('.deep .nested .item')返回的元素若嵌套在7层<div>内，调用getComputedStyle就会明显卡顿 - 滚动列表或频繁hover时掉帧，且卡顿集中在样式计算阶段
排查方法：
- 控制台运行脚本扫描深度 ≥6 的节点（例如用
node.compareDocumentPosition或递归计数） - 右键 Elements 面板节点 → “Show DOM properties” 查
node.depth
calc(var(--x) * 2) 失去静态优化能力
calc(16px + 8px) 可被浏览器提前折叠，但 calc(var(--spacing) * 2) 必须保留运行时解析逻辑：每次重绘都要重新查找变量、解析表达式、执行运算。它无法缓存，也无法合并，等于把本该编译期完成的事拖到每一帧。
立即学习“前端免费学习笔记（深入）”；
影响范围不止动画：
- 使用
transform: translateX(calc(var(--offset)))的滚动容器 - 含
width: calc(var(--col-width) * 3)的响应式网格 - 任何在
requestAnimationFrame中反复读取并计算的场景
关键限制：
- Safari 15.4 之前不支持
cubic-bezier(var(--x1), ...)这类函数内嵌写法 - 所有主流引擎（Blink/Gecko/WebKit）都严格按规范执行——变量求值晚于语法解析，不可能提前折叠
循环中 setProperty + getComputedStyle 强制同步计算
JS里连续调用 el.style.setProperty('--x', '100px') 后紧接 getComputedStyle(el).getPropertyValue('--x')，浏览器必须立刻回溯计算并返回结果，跳过正常异步样式更新流程，引发 layout thrashing。
典型踩坑点：
- 批量更新卡片样式时，对每个
.card先设变量再读取用于后续计算 - 用
for循环驱动动画帧，每轮都设变量+读取+计算位移 - 未用
requestIdleCallback或防抖包裹，导致主线程持续被抢占
更隐蔽的问题：
- 即使只改一个元素的
display，浏览器也会对所有匹配该变量作用域的节点重新验证路径 - 某些 polyfill（如
css-vars-ponyfill）在IE中动态更新时也需手动触发重计算，否则读不到新值
变量定义位置不当放大性能损耗
把所有变量全挂 :root 看似统一，实则让每个 var() 查找都得从最顶层开始。实际应按组件粒度就近定义：比如 .card { --color: #333; }，而不是靠 :root 统一管理再层层继承。
真正影响性能的不是变量数量，而是「查找深度 × 调用频次 × 计算复杂度」三者叠加。哪怕只用3个变量，若都在12层深的节点上调用 calc(var(--x) * var(--y) + var(--z))，照样卡死。
容易被忽略的关键事实：
- 这种开销不会在DevTools的“Network”或“Console”里报错，只会在“Performance”里表现为长任务和高CPU占用
- 构建工具（PostCSS/Sass）完全无法检测或优化这类运行时行为——它们只管输出CSS文本，不管浏览器怎么算
