CSS变量本身不引发重排，但绑定到布局属性（如padding、width）并在循环中频繁读写getComputedStyle+setProperty时会触发隐式重排；应将样式读取提至循环外、批量操作用class切换或合并style设置，并仅将变量用于合成层友好属性（如transform、opacity）。
直接改 --color 或 --size 不会卡顿，但一旦和布局属性绑定、又在循环里频繁读写，性能就断崖式下跌。关键不是“能不能改”，而是“在哪改、怎么改、改给谁看”。
避免在 for / forEach 中反复调用 getComputedStyle + setProperty
这是最典型的隐式重排陷阱：每次 getComputedStyle(el).getPropertyValue('--offset') 都可能触发样式树 recalc，尤其当 el 是深层嵌套节点时，连带父级匹配成本也飙升；而紧跟着 el.style.setProperty('--left', val)，若该变量被用于 left 或 width，每轮都可能触发重排。
- 把变量读取提到循环外：
const rootStyle = getComputedStyle(document.documentElement)，再在循环里复用rootStyle.getPropertyValue('--step') - 批量写入优先走 class 切换：预定义
.step-1 { --step: 1; }、.step-2 { --step: 2; }，循环中只操作el.className = 'step-' + i - 必须动态设值时，合并为单次 DOM 操作：
el.setAttribute('style', '--x:1;--y:2;--z:3;')，而非三次setProperty
只让 CSS 变量绑定合成层友好的属性
CSS 变量本身不重绘，但它的下游属性决定一切。改 --bg-color 很安全，改 --margin 就危险——因为浏览器得重新计算布局。
- ✅ 安全组合：
--scale → transform: scale(var(--scale))（走 GPU 合成层，无重排） - ✅ 次安全组合：
--opacity → opacity: var(--opacity)（不触发布局，重绘范围小） - ❌ 危险组合：
--padding → padding: var(--padding)（强制 layout，极易 layout thrashing） - 验证是否进独立图层：Chrome DevTools → Rendering → 勾选「Layers Borders」，看目标元素是否有绿色边框
用 contain: style 隔离变量作用域
全局变量一动，所有依赖它的元素都要重新计算样式。对高频更新的局部区域，加 contain: style 能让它内部的变量变化不扩散到外部。
立即学习“前端免费学习笔记（深入）”；
- 只对需要隔离的容器加：
.timeline-item { contain: style; } - 它不兼容 IE，且仅对
style类型变量有效（不影响布局/绘制计算） - 配合
will-change: var(--anim-flag)没用——变量值变不会触发will-change生效，得配真实动画属性如transform才行
媒体查询中别指望 var() 自动响应变量变更
@media (max-width: 768px) { .box { width: var(--size); } } 这种写法里，var(--size) 只在样式计算那一刻取值，之后改 --size 不会重新触发媒体查询逻辑。
- 真正要响应断点变化，得在 JS 里监听
matchMedia，然后手动切换变量或 class - 或者干脆在每个断点里重设变量：
@media (max-width: 768px) { :root { --size: 200px; } } - Safari 对
var()在函数内（如hsl(var(--hue), ...)）的支持仍不稳定，生产环境建议加@supports降级
真正卡顿的从来不是变量本身，而是你把它绑到了不该绑的属性上，又在不该刷的地方刷了太多次。变量是胶水，不是加速器；它省的是维护成本，不是渲染开销。
