加了 will-change 反而更卡是因为图层创建失控：浏览器为每个启用该属性的元素分配独立合成层，占用 gpu 内存和纹理缓存；常见错误包括全局声明、滥用非合成属性、动画后未设为 auto、混用冗余提示等；正确做法是仅对 transform/opacity 动画动态添加，并用双 requestanimationframe 精确控制生命周期。
will-change 为什么加了反而更卡
加了 will-change 却更卡，大概率是图层创建失控。浏览器为每个启用该属性的元素分配独立合成层，每层都要占 GPU 内存、纹理缓存和管理开销。100 个列表项全写 will-change: transform，Chrome DevTools Layers 面板里可能显示 “Compositing layers: 127”，滚动立刻发烫掉帧。
常见错误包括：
- 在 CSS 规则里全局写
.item { will-change: transform; }—— 元素一挂载就升层，动画没开始内存先爆 - 用
will-change: left或will-change: width—— 这些属性无法被合成，浏览器忽略提示，还白占资源 - 动画结束不清理，
el.style.willChange = ''（空字符串）—— 实际无效，必须设为'auto'
只对 transform/opacity 动画才有效
will-change 不是“让任意属性变快”的开关，它只对后续真正由 transform 或 opacity 驱动的动画起作用。如果你还在用 left/top 做位移动画，加了也白加 —— 浏览器仍要反复计算布局（reflow），will-change 根本插不上手。
正确做法是两步走：
- 先把动画迁移到
transform: translateX(100px)或opacity: 0.5上 - 再动态加
will-change: transform或will-change: opacity - 避免混用：比如
will-change: transform, opacity同时声明，但动画只改其中一个，多余提示会增加准备成本
JS 动态控制生命周期是唯一靠谱方式
静态写死在 CSS 里等于默认开启“内存泄漏模式”。编辑器、仪表盘这类交互密集场景，必须靠 JS 精确控制“申请-释放”节奏。
推荐写法（注意双 requestAnimationFrame）：
// 动画开始前
element.style.willChange = 'transform';
// 动画结束后，确保绘制完成再清理
requestAnimationFrame(() => {
requestAnimationFrame(() => {
element.style.willChange = 'auto';
});
});
关键点：
- 监听
transitionend或animationend，而不是靠定时器猜时间 - 不用
scroll事件触发 set/remove —— 节流稍慢就会堆积未清理状态 - 移动端尤其敏感，Android 低配机上图层超 20 个就容易触发 OOM
验证是否真起效，别信“看起来顺”
写了 will-change + transform，不代表真走了 GPU 合成。必须用 Chrome DevTools 实锤：
- 打开 More Tools → Layers，悬停目标元素，确认
Reason字段是layer-for-transform（不是仅will-change） - 勾选 Rendering → Layer borders，看到橙色边框才算图层创建成功
- 同时开启 Paint flashing，动画启动时若仍有大面积红色闪烁，说明仍在重绘，优化失败
真正容易被忽略的是：will-change 只解决“动画启动瞬间的卡顿”，如果主线程正被 JS 阻塞（比如在 scroll 回调里频繁读 offsetTop），它救不了。先确保动画属性本身可合成，再谈提示优化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
