chrome 65–79 中 var() 高频更新引发全量样式重计算，导致 fps 下降；应节流 setproperty、集中变量挂载、避免 calc() 混用、优先使用 el.animate() 替代变量动画，并谨慎使用 will-change。
Chrome 65–79 中 var() 表达式高频更新导致样式计算抖动
在 Chrome 65 到 79（2018–2020 年间主流版本）中，var() 的值被频繁修改时（比如每帧调用 element.style.setProperty('--x', val)），浏览器会触发全量样式重计算（style recalc），即使变量只用于 transform。这不是 bug，而是当时引擎对自定义属性依赖链的粗粒度追踪机制所致——只要某个 --x 变更，所有用到它的选择器都会被标记为“需重新计算”，不管是否实际影响布局。
常见错误现象：requestAnimationFrame 里每帧设一次 --progress，配合 transform: scaleX(var(--progress))，结果 FPS 掉到 30 以下，DevTools 的 “Rendering” 面板显示大量黄色的 “Recalculate Style” 耗时峰值。
- 避免在
raf循环中直接调用setProperty：哪怕只是改一个变量，也建议节流到 ≤ 60fps 实际需要的粒度（例如 16ms 间隔内最多更新 1 次） - 把变量集中挂载到单个元素上（如
:root或一个空<div id="vars"></div>），而不是分散在多个 DOM 节点上——减少 style recalc 的触发范围 - 不用
calc(var(--x) + 10px)这类混合表达式：旧版 Chrome 对含calc()的var()依赖解析更慢，优先用纯变量值，如transform: translateX(var(--tx))，且确保--tx值本身带单位（'120px'而非'120'）
用 el.animate() 替代 JS 控制 CSS 变量做动画
Chrome 71+ 已完整支持 Web Animations API，而它绕过了 CSS 变量的解析路径，直接驱动合成层。实测在 Chrome 75 下，用 el.animate({ transform: ['translateX(0)', 'translateX(200px)'] }, { duration: 300 }) 比用变量 + transition 省掉约 40% 的主线程样式计算时间。
适用场景：线性/关键帧明确的动画（入场、缩放、位移），不适用于需 JS 实时响应的交互式拖拽或物理模拟。
- 动画启动后，浏览器自动创建合成层，无需手动加
will-change - 动画结束时自动清理资源，不会像
setProperty那样留下残留依赖 - 若必须和变量联动（如根据主题色动态调整动画终点），可用
getComputedStyle(el).getPropertyValue('--color')读取一次初始值，再传给animate()，避免循环读写
will-change: transform 在旧版 Chrome 中的副作用
Chrome 68–77 对 will-change 的实现不够成熟：一旦设置，即使动画已结束，合成层也不会自动销毁，长期占用 GPU 内存；更糟的是，若变量值非法（如 --tx: 200 缺单位），浏览器会回退到主渲染管线，但 will-change 仍挂着，导致后续所有样式更新都变慢。
正确做法是严格配对控制：
- 仅在动画开始前 1 帧设置：
el.style.willChange = 'transform'; - 监听
animationend或用el.getAnimations().forEach(a => a.onfinish = () => el.style.willChange = 'auto') - 绝对不要在 CSS 里写
.animated { will-change: transform; }——这会让所有匹配元素从挂载起就常驻合成层
真正卡顿的根源往往不是变量本身，而是变量更新方式和浏览器旧引擎对依赖关系的处理逻辑。Chrome 80+ 已大幅优化 var() 更新路径，所以如果你还在维护兼容 Chrome 70 左右的项目，优先砍掉高频 setProperty，换成 animate() 或 CSS @keyframes 驱动的方案，比调参数更有效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
