修改CSS变量本身不触发重绘，但被大量元素引用时会因样式失效标记导致千级节点重算样式，尤其绑定布局属性或嵌套calc()时性能陡降。
修改 CSS 变量本身不直接重绘，但一旦它被大量元素通过 var(--x) 引用，浏览器就必须为所有依赖该变量的计算样式节点重新走一遍样式计算流程——这才是大面积重渲染的根源。
为什么 setProperty 一调就触发整页重算
浏览器不会“监听”变量变化，而是靠“样式失效标记（style invalidation）”被动响应。当你执行 document.documentElement.style.setProperty('--color-primary', '#ef4444')，真正触发重算的不是这行 JS，而是后续：所有已计算出 color: var(--color-primary) 的元素，其 computed style 被标记为“过期”；如果这个变量还同时用于 border-color、box-shadow、background，那一个变量更新就可能让数百个样式声明集体失效。
- 检查方式：在 Elements 面板点任意使用该变量的元素 → Styles → Computed → 搜索
--color-primary→ 看 “Used by” 列是否列出几十甚至上百个匹配项 - 性能验证：Performance 面板录制切换动作，重点看
Recalculate Style的 Self Time 是否 > 5ms、Affected Nodes 是否破千 - 常见误判：Paint Flashing 只闪一小块，不代表没影响；真正耗时的是 Styles 面板里批量样式重计算
大面积继承变量比局部变量更危险
当 :root 定义的 --bg-color 被 200 个组件通过 background-color: var(--bg-color) 继承，它就不再是“一个颜色”，而是一个全局信号源。每次更新，浏览器必须逐个检查这 200 个组件是否仍匹配该变量引用链——尤其当变量嵌套了 calc() 或跨层引用（如 --bg: var(--bg-base)），匹配成本指数级上升。
- 风险放大器：
calc(var(--scale) * 1rem)这类表达式会让浏览器无法提前缓存计算结果，每次都要重新解析变量值再运算 - 真正瓶颈不在 JS 调用频次，而在 CSS 规则本身的结构：一个变量被散落在
.header、.card、.btn、伪元素、@media嵌套中，等于给每个节点都加了一层运行时依赖 - 安全替代：把高频更新的交互态变量（如 hover 色、加载缩放）和主题色拆开，避免共用同一个变量名
哪些写法会让变量更新必然卡顿
不是所有 var() 都平等。以下用法会显著提高重算代价，甚至触发强制重排：
立即学习“前端免费学习笔记（深入）”；
- 绑定布局属性：用
--margin控制margin: var(--margin)—— 改一个值就要重算位置和尺寸 - 嵌入函数参数：
background: linear-gradient(to right, var(--start), var(--end))—— Safari 对此类更新响应滞后，常出现一帧空白 - 与
contain: paint或will-change: transform共存 —— 变量更新可能触发图层边界重估，引发合成层销毁-重建 - 在
scroll或resize回调里直接调用setProperty—— 每秒触发数十次，远超渲染帧率
真正容易被忽略的是：变量本身不抖，抖的是浏览器对“谁用了它”的实时追踪逻辑。优化方向不是少写 var()，而是控制它的作用域、更新节奏和绑定属性类型——比如用 @layer motion 隔离动画变量，或用 requestIdleCallback 节流主题切换。
