CSS变量本身不触发重排重绘，但在嵌套循环中频繁读写并绑定布局属性时会放大性能风险；应避免热路径裸用，改用预计算、class切换、批量设置或contain: style隔离。
CSS 变量本身不会直接触发重排或重绘，但它们在嵌套循环中被频繁读写、配合布局属性使用时，会放大性能风险——尤其当 JS 在循环里反复读取 getComputedStyle 并修改 style.setProperty 时。
为什么 CSS 变量 + 嵌套循环容易出问题
浏览器对 CSS 变量的解析是惰性的，变量值只在需要时计算（比如样式生效、getComputedStyle 调用）。但嵌套循环会成倍放大这种“按需计算”的开销：
- 每次
getComputedStyle(el).getPropertyValue('--size')都可能触发样式树 recalc，若 el 位于深层嵌套结构中，连带父级匹配成本也上升 - 循环中连续设置
el.style.setProperty('--offset', i + 'px')，若该变量被用于left或width等布局属性，每轮都可能触发重排 - 多个元素共用同一组变量（如
--theme-color）且在循环中批量切换，若未隔离渲染区域，重绘范围会扩散
避免在 for / forEach 中直接读写 CSS 变量
这不是语法错误，而是隐式性能陷阱。重点不是“不能用”，而是“不该在热路径里裸用”：
- 把变量读取提到循环外：先
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
用 contain: style 隔离变量作用域
CSS 变量默认是全局继承的，一个根变量变动，所有依赖它的元素都要重新计算样式。而 contain: style 能让子树独立维护自己的变量作用域：
立即学习“前端免费学习笔记（深入）”；
- 给频繁更新变量的容器加
style-container { contain: style; }，其内部--item-size的变化不会触发外部元素的 style recalc - 注意：它不兼容 IE，且仅对
style类型变量有效（即仅影响样式计算，不影响布局/绘制） - 搭配
will-change: var(--anim-flag)要谨慎——变量值变不会自动触发 will-change 生效，得配合真实动画属性（如transform）才起作用
真正要盯住的，是变量背后的布局属性
CSS 变量只是“中间层”，卡顿源头永远是它绑定的那个属性：
- ✅ 安全组合：
--scale→transform: scale(var(--scale))（合成层，无重排） - ❌ 危险组合：
--margin→margin-left: var(--margin)（触发布局，循环中极易 layout thrashing） - ⚠️ 隐性风险：
--color→background: hsl(var(--hue), 70%, 60%)看似只重绘，但若父容器有filter: blur(2px)，整块区域会被提升为单独图层，内存压力陡增
变量本身很轻，但一旦和布局、滤镜、阴影等高代价属性耦合，又处在循环执行流里，就很容易在低端设备上掉帧。别只盯着 setProperty 耗时，得顺藤摸瓜看它最终映射到哪个 CSS 属性上。
