CSS变量动画不等于高性能动画，关键在于变量必须驱动transform或opacity等合成属性，否则会触发重排重绘；错误示例是用变量控制left、width等非合成属性，正确做法是通过calc()将变量注入translate/scale等transform值中。
为什么 CSS 变量动画不等于高性能动画
直接用 --color 或 --scale 配合 transition 做动画，大概率触发重排（reflow）甚至重绘（repaint），根本没提速。关键不在“用了变量”，而在“变量改的是哪个属性”。浏览器只对 transform 和 opacity 这两个属性做合成层优化（compositor-only），其余任何变量驱动的 left、width、background-color 改变，都会导致 Layout → Paint → Composite 流程全走一遍。
常见错误现象：transition: --x 0.3s 看似简洁，但毫无意义——CSS 自定义属性本身不触发渲染，必须通过 calc() 或函数注入到可动画属性中；而一旦注入到非合成属性，性能就垮了。
- ✅ 正确路径：用变量控制
transform: translateX(calc(var(--x) * 1px)) - ❌ 错误路径：用变量控制
left: calc(var(--x) * 1px)或margin-left: var(--x) - 变量本身不参与渲染流水线，它只是“值容器”；真正决定性能的是最终被修改的 CSS 属性
如何让 CSS 变量真正跑在合成层上
核心是把变量值“导出”到 transform 或 opacity，且避免表达式里出现触发布局的计算（比如 calc(100vw - var(--offset)) 中的 100vw 是相对视口的，每次取值都可能触发 layout）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只用
transform: translateX(var(--tx)) translateY(var(--ty)) scale(var(--s)) rotate(var(--r))—— 所有值必须是带单位的合法 transform 值（如24px、1.2、45deg） - 避免在
calc()中混用相对单位和变量，例如calc(var(--x) + 1rem)可能迫使浏览器同步计算 rem 值 - 给动画元素加
will-change: transform（仅在必要时，别滥用）或提前用transform: translateZ(0)创建合成层 - Chrome DevTools → Rendering → “Paint flashing” 和 “Layer borders” 可直观验证是否真进了合成层
JavaScript 修改变量时的性能陷阱
用 element.style.setProperty('--x', '120') 没问题，但高频调用（比如 requestAnimationFrame 里每帧都设）会引发样式计算抖动，尤其当该变量被多个元素共享或用于复杂 calc() 表达式时。
更稳的做法：
- 优先用
transform的原生 API（如el.animate()）替代 JS 控制变量，浏览器对它做了深度优化 - 如果必须用变量，把所有动画变量集中到一个伪元素或根元素上，减少 style recalc 范围
- 避免在变量值里拼字符串单位，比如
set('--x', '120px')比set('--x', 120 + 'px')少一次字符串拼接（微小但真实） - 不要监听
transitionend去读取变量值——变量不是状态源，DOM 属性或getComputedStyle返回的才是实时渲染值
兼容性与 fallback 的务实处理
CSS 变量在 IE 完全不支持，Edge 15+、Chrome 49+、Firefox 31+ 支持。但“支持变量”不等于“支持变量驱动的动画性能”，旧版 Chrome 对 transform 中嵌套 var() 的优化很弱。
稳妥策略：
- 用
@supports (animation-timeline: worklet)这类现代特性检测代替 UA 判断 - 对关键交互动画，准备两套：变量版（现代浏览器） + class 切换版（降级，用预设的
transform: translateX(120px)类） - 避免在
@keyframes内直接引用变量（to { transform: translateX(var(--end)) }），它不会动态响应变量变化；应改用element.animate()或 JS 驱动 - PostCSS 插件如
postcss-css-variables可静态替换变量，但会丢失运行时灵活性，适合纯配置型动画
真正难的不是写对语法，而是判断哪一帧的变量更新会让浏览器多走一次 Layout —— 这得靠 DevTools 的 Layers 和 Performance 面板盯住每一帧的耗时分布。
