will-change 不是性能加速器而是图层预分配指令，滥用会导致 GPU 内存溢出或卡死；仅对 transform 和 opacity 有效，对 left、width 等盒模型属性无效；安全用法仅限 JS 动态控制且满足动画属性、实测帧率等三条件。
will-change 不能滥用于所有盒模型元素，因为它不是性能加速器，而是图层预分配指令——加一个，浏览器就真建一块 GPU 内存；加多了，直接 OOM 或卡死。
will-change 一加就卡，根本原因是它强制升层
浏览器对 transform 和 opacity 的硬件加速在 Chrome 98+ 已默认启用，will-change 不再是“开启加速”的开关，而是“提前下单建图层”的指令。一旦声明 will-change: transform，浏览器会立即为该元素创建独立合成层（composited layer），并预分配 GPU 内存。这不是延迟加载，是立刻执行。
- 每个匹配元素都单独升层 → 图层数量爆炸（DevTools > Layers 面板可验证）
- Android 4.4–6.0 WebView 中图层不自动释放，内存持续上涨，30 秒内可能触发
Out of Memory - 即使元素没动，只要 CSS 里写了
will-change，图层就常驻；静态写死如* { will-change: transform }等于主动制造内存泄漏
哪些盒模型属性加了 will-change 也完全无效
will-change 只对能走合成路径的属性起作用，而盒模型中大量常用属性触发布局（reflow）或重绘（paint），浏览器根本不会响应这个提示。
-
will-change: left、will-change: top、will-change: width、will-change: margin-top：全部无效，浏览器忽略，但图层仍被错误创建（浪费资源） -
will-change: background-color、will-change: box-shadow：触发重绘，无法合成，will-change不提升性能，只增开销 -
will-change: contents：高危操作，会让整个子树升层，10 行文本可能拉出 20+ 图层，严禁用于任何盒模型容器
滚动容器里加 will-change: transform 是个常见误解
给 overflow: scroll 容器加 will-change: transform 确实能提升滚动流畅度，但原理不是“优化滚动”，而是“骗浏览器提前升层”。它有效，但有严格前提：
立即学习“前端免费学习笔记（深入）”；
- 仅适用于容器本身（如
.scroll-container），不能加在内部滚动项（如.list-item）上 - 必须配合
contain: strict或transform: translateZ(0)确保图层隔离，否则子元素仍可能污染合成边界 - 若容器父级有
overflow: hidden或clip-path，图层会被裁剪失效，will-change白加
真正安全的用法只有三类动态场景
静态写死在 CSS 文件里的 will-change 基本等于埋雷。唯一可靠的方式是 JS 动态控制，且必须满足三个硬条件同时成立：
- 动画只用
transform或opacity（检查 @keyframes 或 transition 中无top/width/color等） - 已用 DevTools FPS Meter 实测帧率
- 只作用于动画的直接载体元素（如
.card），绝不作用于body、通用类或父容器
动态添加后，必须用双帧 requestAnimationFrame 清理：element.style.willChange = 'auto'，否则图层残留导致后续滚动/动画抖动。
最容易被忽略的点：will-change 不解决布局抖动、JS 阻塞或图片解码慢——它只管合成层调度。如果卡顿根源不在这里，加了反而更卡。
