will-change 一加就卡甚至OOM，因其强制浏览器预分配GPU内存建合成层，50个元素同时启用会导致Android 4.4–6.0 WebView内存持续上涨而崩溃；应仅在transform/opacity/scroll-position且高频变化时动态添加并及时清除。
will-change 为什么一加就卡，甚至导致 OOM
它不是开关，是“提前下单”，但浏览器真会照单生产图层。每个 will-change: transform 都可能让浏览器分配一块 GPU 内存来建独立合成层；如果页面里有 50 个列表项都写了这个声明，就等于同时预定了 50 块显存——尤其在 Android 4.4–6.0 的 WebView 里，这些图层不自动释放，内存持续上涨，30 秒后直接触发 Out of Memory 崩溃。
常见错误现象包括：
- 滚动变慢、文字模糊（图层缩放失真）
- 动画启动延迟明显，首帧掉帧严重
- DevTools 的
Layers面板里图层数量居高不下，切换路由后也不回落
哪些场景下可以安全加 will-change
只在「明确即将变化 + 变化高频 + 属性合规」三者同时满足时才考虑。浏览器不会为 left、top、background-color 加速，will-change: left 纯属无效提示，还多占资源。
真正可用的组合只有：
立即学习“前端免费学习笔记（深入）”；
-
will-change: transform（配合translate/scale/rotate） -
will-change: opacity（仅用于透明度渐变） -
will-change: scroll-position（极少数需监听滚动位置的容器，如自定义滚动条）
注意：will-change: contents 是高危写法，会让整个子树升层，10 行文本就能拉出 20+ 图层，必须禁用。
怎么动态加、什么时候必须删
静态写死在 CSS 里（比如 .card { will-change: transform; }）是最大误区。正确路径是 JS 控制生命周期：交互触发瞬间加，动画结束立刻清。
实操建议：
- 用
mouseenter、touchstart或click触发element.style.willChange = 'transform' - 监听
animationend（不是transitionend），回调里设element.style.willChange = 'auto' - 如果是 requestAnimationFrame 驱动的 JS 动画，在第一帧设，最后一帧清
- 避免用
setTimeout模拟延迟清除——它不保证在渲染帧边界执行，容易漏清
比 will-change 更稳的硬件加速替代方案
多数情况下，transform: translateZ(0) 或 transform: translate3d(0, 0, 0) 就够用。它不依赖 JS 控制，无内存泄漏风险，兼容性更好，且现代浏览器对这类写法已有成熟优化。
适用场景：
- 固定尺寸按钮、图标、卡片入场动效
- 模态框淡入 + 缩放组合动画（合并到单个
transform声明里） - 不需要频繁启停的常驻动效元素
关键区别：translateZ(0) 图层常驻，但开销可控；will-change 图层按需创建，但一旦失控就是内存雪崩。旧安卓机上，前者比后者更扛造。
真正要盯住的不是“有没有加 will-change”，而是“图层是否在动画结束后真实销毁”。每次改完，务必打开 Chrome DevTools → Rendering → 勾选 Layer borders 和 FPS meter，滑动、触发动画、再静置 2 秒，看图层数量是否回落。不验证，就等于没优化。
