will-change 是 GPU 内存预占指令，非优化开关；每设一个即强制分配 ≥4MB 纹理内存且不自动释放，静态滥用（如全局或伪类）会导致图层堆积、上传阻塞甚至 OOM。
will-change 创建过多图层会直接拖垮性能，因为它不是“优化开关”，而是“GPU内存预占指令”——加一个，浏览器就真分配一块 GPU 纹理内存（通常 4MB 起），且不自动释放。
图层创建是强制的，不是建议的
浏览器看到 will-change: transform，不会判断“这个元素会不会动”或“动多久”，而是立刻执行三件事：分离图层、上传纹理、绑定合成器线程。这个过程发生在 DOM 挂载或样式计算阶段，和后续是否有动画完全无关。
- 静态写在 CSS 里（如
.item { will-change: transform; }）→ 一屏 30 个列表项 = 30 个常驻图层 - 移动端 WebView（Android 4.4–6.0）根本不会回收闲置图层，哪怕动画只持续一帧
- iOS Safari 对图层常驻极度敏感，超过 10～15 个就可能触发合成器中断，出现白屏或掉帧
GPU 内存不是无限的，尤其在中低端设备上
每个合成层至少占用 4MB GPU 纹理内存。当图层数量快速上升时，会出现两类硬性瓶颈：
- 纹理上传阻塞：中低端安卓机图层超 5～8 个后，CPU → GPU 的上传通道开始排队，
requestAnimationFrame帧被卡在等待纹理就绪阶段 - 内存溢出（OOM）：20+ 图层 × 4MB ≈ 80MB GPU 内存，部分低端 Android 设备 GPU 内存上限仅 128MB，页面滚动几秒就崩溃
- DevTools 中可验证：
Layers面板图层数持续上涨，Performance面板中GPU Memory曲线直线上升而非波动
哪些 will-change 写法等于主动制造图层垃圾
这些用法看似合理，实则全在无效建层：
立即学习“前端免费学习笔记（深入）”；
-
will-change: left或will-change: width→ 浏览器忽略提示，但图层仍被错误创建（因属性无法合成） -
will-change: contents→ 强制整个子树升层，1 行文本可能触发 5+ 子节点图层 -
div:hover { will-change: transform; }→ hover 进去时建层，hover 离开后不清理，反复悬停=图层堆积 -
* { will-change: transform; }→ 全局污染，连<body>都被拉进 GPU 图层
真正有效的图层控制只有一条路径
必须靠 JS 动态管理生命周期，且时机精确到帧级：
- 添加时机：在用户真实交互触发瞬间，比如
touchstart或mouseenter后、transformclass 应用前的那一帧 - 清除时机：监听
animationend（不是transitionend），或在requestAnimationFrame最后一帧设回auto - 绝不能依赖 CSS 伪类或全局规则；也绝不能在
scroll事件里节流后 set/remove —— 节流延迟会导致未清理图层堆积
最易被忽略的一点：will-change 不解决 Layout 或 Paint 瓶颈。如果 Performance 面板显示卡在 Layout 或 Paint，加它毫无意义——先用 contain: content 或重构 DOM 结构，再谈图层优化。
