will-change在android 4.4–6.0 webview中强制建层且永不回收，直接导致oom崩溃；它将transform等声明视为硬性指令，立即分配gpu内存并常驻至页面卸载，50个元素10秒内即可触发白屏或进程被杀。
will-change 在 Android 4.4–6.0 WebView 中强制建层且永不回收
这不是“可能变慢”，而是直接 OOM 崩溃。这些旧版 WebView 把 will-change: transform 当作硬性指令：DOM 挂载或样式匹配一发生，立刻分配 GPU 纹理内存、创建独立合成层，并且**不会随动画结束、鼠标移开或滚动停止而释放**。哪怕一个元素只动一帧，图层就常驻到页面卸载。
实测中，.list-item { will-change: transform; } 匹配 50 个列表项，低端安卓机 10 秒内 GPU 内存飙升至 400MB+，随后白屏或 WebView 进程被系统强杀。
DevTools → Layers 面板里能看到图层数量持续上涨，筛选内存 >2MB 的图层，点开会发现全是批量渲染的 item 或弹窗容器——这就是崩溃前兆。
哪些 will-change 值在移动端完全无效还更耗资源
will-change 只对三个属性真正起作用：transform、opacity、scroll-position。其他所有写法，不仅不加速，反而白占 GPU 内存：
-
will-change: left、will-change: width、will-change: margin：这些触发 layout/paint，浏览器要么忽略，要么建图层但动画仍走 CPU 渲染 -
will-change: contents：强制整个子树升层，10 行文本可能生成 20+ 图层，极易图层爆炸 -
will-change: background-color或混用box-shadow：关键帧里出现任一非合成属性，整段动画降级回 CPU 渲染
动态控制不是“更好”，是唯一能避开崩溃的路径
静态写进 CSS（比如全局 .card { will-change: transform; }）等于主动制造内存泄漏。安全做法必须满足三个硬条件：
- 添加时机：
touchstart、mouseenter或animationstart触发后、动画 class 应用前那一帧，用 JS 设置el.style.willChange = 'transform' - 清除时机：必须监听
animationend（不是transitionend），并设回'auto'；iOS Safari 对 ≤16ms 动画可能不触发事件，需加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100) - 范围控制：只对「即将开始动画」的单个元素操作，绝不对列表项、网格项批量设置
验证是否真生效，别信“看起来流畅”
写了 will-change 和 transform，不代表 GPU 加速已启用。必须看底层行为：
- Chrome DevTools → Cmd+Shift+P 输入 “Rendering” → 勾选
Layer borders：真实启用会看到橙色边框；若满屏都是，说明图层失控 - 勾选
Paint flashing：滚动时满屏绿色闪动，说明重绘区域失控，will-change已失效 - Performance 面板录制滚动过程：GPU Memory 曲线若持续爬升而非稳定波动，就是图层没回收
最易被忽略的一点：will-change 本身不节省 CPU 时间，它只换来 GPU 内存开销——只有当你确认某元素已在做纯 transform/opacity 动画、且帧率实测低于 55fps 时，才值得引入，并必须配 JS 动态控制生命周期。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
