will-change 不是“加了就快”的开关，仅对 transform 和 opacity 有效，须 JS 动态设置并用双 requestAnimationFrame 清理为 'auto'，静态声明易致图层爆炸、内存暴涨、低端机卡死。
直接说结论：will-change 不是“加了就快”的开关，它只对 transform 和 opacity 有效，且必须动态设置、精确清理；静态写死在 CSS 里（比如 .item { will-change: transform; }）大概率导致图层爆炸、内存暴涨、低端机卡死。
为什么will-change: transform加了反而更卡
浏览器看到 will-change: transform，会立刻为该元素创建独立合成层、预分配 GPU 内存、上传纹理。但若元素没真动，或只动一次就停，这些资源全白占着——中低端安卓机图层数超 5～8 个后，纹理上传开始阻塞，帧率从 60fps 掉到 20fps；iOS Safari 更敏感，常驻图层过多可能直接白屏。
- 全局声明
.list-item { will-change: transform; }→ 一屏 20 项 = 20 个常驻图层 - 用在
left、width、background-color上 → 浏览器忽略提示，还白占资源 - 动画结束设
element.style.willChange = ''→ 实际无效，必须设为'auto' -
will-change: all或will-change: contents→ 浏览器无法预判，或强制子树全升层，极易图层爆炸
只对transform和opacity生效，其他属性加了白费
will-change 的底层机制是让浏览器跳过 Layout 和 Paint，直奔 Composite 阶段。但只有 transform 和 opacity 能走这条通路。其他任何属性都不行：
-
left/top→ 改用transform: translateX(100px) -
width/height→ 若需缩放，优先用transform: scaleX(2)，注意transform-origin -
background-color→ 加will-change无意义，仍触发重绘 -
rgba()改 alpha → 仍属颜色重绘，不如直接用opacity
必须 JS 动态控制生命周期：双 requestAnimationFrame 是底线
静态写死等于默认开启“内存泄漏模式”。真正可控的方式是：动画前一刻设，动画结束后确保绘制完成再清。
立即学习“前端免费学习笔记（深入）”；
- 动画开始前：
element.style.willChange = 'transform, opacity'; - 监听
animationend或transitionend触发清理（别用mouseleave或scroll） - 清除必须用双
requestAnimationFrame：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 移动端尤其敏感，Android 低配机上图层超 20 个就容易触发 OOM
验证是否真起效，别信“看起来顺”
写了 will-change + transform，不代表真走了 GPU。Lighthouse 检测不到 JS 动态设置的值，它只扫静态 CSS。
- 打开 Chrome DevTools → More Tools → Layers 面板
- 手动触发动画，看目标元素是否出现在图层列表中
- 确认
Reason字段显示layer-for-transform或layer-for-opacity - 注意：若父容器有
overflow: hidden、filter: blur(0.1px)或非 identity 的transform，会压制子元素图层，will-change失效
最易被忽略的一点：will-change 是提示，不是指令。浏览器是否建层、何时回收，由实现决定，不可控。所以它永远不该是第一优化手段——先确保动画本身已用 transform/opacity 实现，再考虑要不要加这行提示。
