will-change 通过提前创建独立合成层，使动画仅执行轻量的 composite 阶段，避免 layout 和 paint 导致掉帧；仅 transform 和 opacity 有效，滥用会因图层过多反而卡顿。
will-change 为什么能减少掉帧？本质是绕过 Layout 和 Paint
掉帧的核心原因是浏览器每帧执行了太多工作，超出了 16.7ms 的预算。而 will-change 不是“加速动画”，而是让浏览器提前把元素放进一个独立合成层（compositing layer），后续只走 Composite 阶段——这是整条渲染流水线中最轻量的一环。
比如你对一个元素做 transform: translateX(100px) 动画，若没加 will-change，浏览器可能在第一帧才决定要不要升层；而加上后，它会在动画开始前就创建图层、分配 GPU 纹理、隔离绘制上下文。这样动画过程中就不再触发 Layout 或 Paint，避免主线程卡住。
哪些值真正有效？不是所有属性都值得加 will-change
will-change 只对后续实际由 transform 或 opacity 驱动的动画起作用。其他值要么被忽略，要么白占资源：
-
will-change: transform✅ 有效，且最常用 -
will-change: opacity✅ 有效，适合淡入淡出场景 -
will-change: left❌ 无效，left触发 Layout，浏览器直接无视该提示 -
will-change: width❌ 同上，且会误导开发者以为“加了就有用” -
will-change: scroll-position⚠️ 仅用于滚动容器，且需配合contain: paint才有明显收益
为什么加了 will-change 反而更卡？常见误用场景
性能变差几乎全是图层滥用导致的。GPU 内存和纹理缓存是有限资源，每个合成层都要占用：
- CSS 中全局写
* { will-change: transform; }—— 页面一加载就升层上百个，DevTools Layers 面板里图层数爆表 - 动画结束后没清理：
el.style.willChange = ''是无效的，必须设为'auto' - 混用冗余提示，如
will-change: transform, opacity，但动画只改transform，多分配一层无用资源 - 在父容器上加
will-change，结果子元素全被连带升层（尤其配合overflow: hidden时）
怎么加才对？动态控制生命周期是关键
静态写在 CSS 里基本等于滥用。正确做法是用 JavaScript 精确控制“升层时机”和“降层时机”：
- 动画开始前一帧，用
requestAnimationFrame设置el.style.willChange = 'transform' - 再套一层
requestAnimationFrame（即双 rAF），确保样式已 flush，再触发动画 - 动画结束（监听
transitionend或用setTimeout延迟一帧），设回el.style.willChange = 'auto' - 如果动画由 hover 触发，不要在 :hover 伪类里写
will-change，仍需 JS 控制
复杂点在于：图层创建本身有开销，提前太久（比如鼠标悬停前 500ms 就升层）反而引入延迟；太晚（动画已开始才升）又来不及优化。真实项目里，这个窗口往往只有 1–2 帧。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
