will-change 对高频动画基本无效，甚至更卡；仅 transform、opacity、filter、backdrop-filter 能触发硬件加速，静态声明已失效，动态设置+双 requestanimationframe 清除才安全。
will-change 对高频动画基本无效，甚至会让它更卡——除非你只动 transform 或 opacity，且已确认掉帧。
哪些值真正触发硬件加速？
浏览器只对极少数 CSS 属性响应 will-change 并创建合成层：transform、opacity、filter、backdrop-filter 是目前被主流浏览器（Chrome 98+、Safari 16.4+、Edge 114+）实际支持的值。
-
will-change: left或will-change: top→ 强制触发布局（reflow），浏览器忽略或回退到软件渲染 -
will-change: width、will-change: background-color→ 不生成图层，还可能干扰后续真实动画的分层时机 -
will-change: all→ Chrome 90+ 和 Safari 15.4+ 直接无视 -
will-change: scroll-position→ iOS Safari 完全不支持，别填
为什么静态声明在现代浏览器里基本失效？
Chrome 98+、Edge、Safari 已默认对 transform 和 opacity 动画自动创建合成层。你在 CSS 里写 .anim { will-change: transform; } 不会带来额外收益，反而让所有匹配元素长期驻留图层，内存持续上涨。
- 静态写法等于“永久预约 GPU 资源”，而动画是瞬时行为
- 一屏 20 个列表项都带该声明 → GPU 图层数飙升，滚动直接掉帧
- 移动端尤其敏感：iOS Safari 图层管理更保守，常驻图层易引发白屏或卡死
动态设置 + 双 requestAnimationFrame 清除才是安全写法
必须在动画开始前 1–2 帧设 will-change，并在动画结束后确保图层稳定存在过再清除，否则闪屏、撕裂、内存泄漏风险明显。
- 动画开始前：
element.style.willChange = 'transform'; - 动画结束后（例如监听
animationend或transitionend）：requestAnimationFrame(() => {requestAnimationFrame(() => {element.style.willChange = 'auto';});}); - 第一层：进下一渲染帧；第二层：确保该帧已完成绘制，图层已稳定参与合成
- 别在父容器和子元素同时设 —— 比如
.list和.item都加transform，图层嵌套放大开销
真正卡顿时，先看 Performance 面板再决定要不要加
打开 Chrome DevTools → Performance → 录制一段动画，重点观察主线程负载分布：
- ✅ 加的信号：主线程空闲，但
Composite阶段延迟高、首帧明显滞后、帧率低于 60fps，且动画只用transform/opacity - ❌ 别加的信号：主线程满载、大量
Layout或Paint占比高 → 这说明问题在 JS 阻塞或样式重算，加will-change白费 - 用
Layers面板确认图层数：稳定在 3～5 层为佳，超过 8 层就要立刻排查
它不是性能开关，而是资源预约指令。约早了浪费，约错了失效，约多了拖垮整页。别把它当“动画加速器”贴满页面。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
