will-change 是预约单而非开关，滥用会导致旧安卓和 ios safari 因图层不回收而 oom；需在交互触发、动画开始前动态添加，并在 transitionend/animationend 后立即清理。
will-change 不是开关，是预约单；滥用它等于让浏览器提前开几百个空房间，等不到人来，内存就先满了。
will-change 为什么在旧安卓和 iOS Safari 上直接 OOM
它触发的是合成层（Compositing Layer）的预创建，每个层都对应一块 GPU 纹理内存。旧安卓 WebView（4.4–6.0）和 iOS Safari 对“闲置图层”几乎不回收——一旦加了 will-change: transform，哪怕动画早结束了，图层还挂着；几十个列表项、轮播图、弹窗同时驻留，单个图层占几 MB，显存瞬间见底。
- Chrome DevTools 的
Layers面板里能看到真实图层数量和内存占用，>2MB 的图层如果归属一堆.item或临时.modal，基本就是滥用信号 - iOS Safari 尤其危险：不释放 + 不警告，只在滚动卡顿、文字模糊、页面白屏时才暴露问题
- 旧安卓更隐蔽：内存曲线持续爬升，Performance 面板里
GPU Memory不回落，但 FPS 看不出异常
哪些写法看似合理，实则埋雷
静态声明、批量绑定、全局覆盖，都是高危操作。浏览器不会区分“真要动”还是“只是写了”，只要看到 will-change，就按提示走流程。
-
will-change: all或will-change: left, top：无效属性照样升层，纯占资源 - Vue/React 列表中对每个
.item都加will-change: transform类：100 条数据 = 100 个图层，滚动即崩溃 -
@keyframes动画未监听animationend：循环播放时图层越积越多，will-change不撤，图层不退 - 滚动容器上写死
will-change: transform：整个可滚动区域长期驻留图层，用户没动手指，内存已在涨
真正“按需”的动态添加时机
所谓“必要时刻”，必须满足两个条件：① 用户交互已触发、动画即将开始；② 元素确实在动、且动的是 transform 或 opacity 这类可合成属性。
- 用
touchstart/mouseenter/click触发添加：el.style.willChange = 'transform' - 动画结束立刻清理：监听
transitionend（加{ once: true }）或animationend，执行el.style.removeProperty('will-change') - 避免用 class 控制：CSS 里写
.is-animating { will-change: transform; }仍属静态声明，JS 添加 class 后浏览器立即升层，无法精准控制生命周期 - 慎用
scroll场景：滚动本身不触发transform，will-change: transform对滚动容器仅是“赌一把”，不如优先优化 DOM 深度和图片懒加载
替代方案比 will-change 更安全
多数卡顿根本不需要 will-change。先确保基础条件成立，再考虑是否加提示。
- 动画属性必须是
transform和opacity：别用left、top、width，这些强制触发布局，will-change救不了 - 用
transform: translateZ(0)或transform: scale(1.001)替代：同样触发合成层，但无“预约开销”，也不创建新层叠上下文 - 检查是否已有隐式升层：
getComputedStyle(el).transform返回非none矩阵，说明已升层，再加will-change是重复劳动 - 媒体查询里禁用
will-change：断点切换时样式重算频繁，叠加图层创建极易爆炸，改用contain: layout paint控制渲染边界更可控
最常被忽略的一点：will-change 的清理不是“可选动作”，而是内存安全的底线。动画结束没删，等于在 GPU 显存里扔垃圾；而低端设备没有回收机制，那堆图层就一直占着，直到用户手动刷新或系统杀进程。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
