will-change 仅对 transform、opacity 等少数属性有效，须动态设置并双 requestAnimationFrame 清除；静态声明无效且易致内存泄漏、卡顿或白屏。
will-change 不是“加了就变快”的开关，它只对 transform 和 opacity 有效，且必须动态设置、及时清除；写死在 CSS 里反而导致 GPU 内存持续上涨、滚动卡顿甚至白屏。
哪些值真能触发图层提升
浏览器只响应极少数 CSS 属性的 will-change 声明：
-
transform：最常用，兼容性好（Chrome 36+、Firefox 36+、Safari 13.1+） -
opacity：需明显变化（如0 → 1），微调（0.99 → 1）通常不触发 -
scroll-position：仅对可滚动容器生效，但 Chrome 98+ 已弱化支持，Safari 完全不支持 -
contents：语义与动画无关，慎用；会禁用子树缓存，易引发重绘放大
以下写法完全无效，甚至有害：
-
will-change: left或will-change: width→ 浏览器忽略或强制触发布局（Layout） -
will-change: background-color→ 不升层，还可能干扰后续真实动画的分层时机 -
will-change: all→ Chrome 90+ 和 Safari 15.4+ 直接无视
为什么静态声明（如 .anim { will-change: transform; }）基本没用
Chrome 98+、Edge、Safari 已默认对 transform 和 opacity 动画自动创建合成层。静态写死等于“永久预约 GPU 资源”：
立即学习“前端免费学习笔记（深入）”；
- 一屏 20 个列表项都带该声明 → 图层数飙升，滚动直接掉帧
- iOS Safari 图层管理保守，常驻图层易引发白屏或卡死
- 低端安卓机图层超 5～8 个，纹理上传阻塞，动画首帧延迟明显
所谓“优化”，本质是把视觉效果从 Layout/Paint 路径，挪到纯 Composite 路径——这不是锦上添花，而是硬性前提。
必须动态设置 + 双 requestAnimationFrame 清除
正确生命周期控制是唯一安全用法：
- 动画开始前 1～2 帧设：
element.style.willChange = 'transform, opacity' - 监听
transitionend或animationend触发清理，别依赖mouseleave或scroll - 清除不能立刻执行，否则图层销毁太早，可能闪屏或撕裂；必须用双
requestAnimationFrame：
element.style.willChange = 'transform';
requestAnimationFrame(() => {
requestAnimationFrame(() => {
element.style.willChange = 'auto';
});
});
第一层进下一渲染帧，第二层确保该帧已完成绘制、图层已稳定参与合成。
验证是否真生效，别信“看起来顺”
加了 will-change 不代表优化成功，Lighthouse 扫不到 JS 动态设置的值：
- 打开 Chrome DevTools → More Tools → Layers 面板，手动触发动画
- 看到元素出现在图层列表中，且 Reason 字段显示
layer-for-transform或layer-for-opacity，才算真正升层 - 若 Reason 是
will-change，仅代表提示收到，不代表已执行优化 - 勾选 Rendering 面板中的 «Paint flashing»：满屏绿色闪动，基本就是
will-change泛滥了
最容易被忽略的一点：will-change 本身不节省 CPU 时间，反而增加 GPU 内存开销——只有当你已经确认后续确实变更了 transform 或 opacity，且该元素确实是性能瓶颈时，才值得引入并精细管理。
