will-change 对 width、height、left、top、margin、padding、border-radius 等盒模型属性完全无效，因其触发 layout 或 paint，无法走纯合成路径；仅 transform、opacity、scroll-position 三者有效，且须严格匹配动画方式并动态管控生命周期。
will-change 对 width、height、left、top、margin、padding、border-radius 等盒模型属性完全无效，加了不仅不加速，还强制创建无用合成层，吃显存、拖帧率、甚至在 Android 4.4–6.0 WebView 中直接 OOM 崩溃。
will-change: width 为什么根本不起作用
浏览器只对能走「纯合成路径」的属性响应 will-change，而盒模型变更必然触发 layout（重排）或 paint（重绘）。will-change: width 这类声明，浏览器要么忽略，要么照单建图层但实际动画仍走 CPU 渲染——等于白占 GPU 内存。
-
width、height、left、top、margin、padding、border-radius全部属于 layout/paint 触发器，无法被合成 - DevTools → Layers 面板里能看到这些元素确实升层了，但图层内容每帧都要重绘，GPU 只是多搬了一次脏数据
- 实测：100 个
.item { will-change: width; }在低端安卓机上滚动 20 秒后内存上涨 400MB+，随后白屏
真正有效的属性只有三个
能被 will-change 实际利用的 CSS 属性极其有限，且必须配合对应动画方式才生效。写错一个，整个优化就失效。
- 仅
transform（需搭配translate/scale/rotate等，不能混用left） - 仅
opacity（透明度渐变，不能和background-color动画混用） - 仅
scroll-position（极少数自定义滚动监听场景，如滚动吸顶条） -
contents是高危项，会让整个子树升层，10 行文字可能拉出 20+ 图层，严禁用于容器
动态控制比写死 CSS 危险十倍
很多人以为 JS 动态加 will-change 就安全，其实更容易翻车——因为时机、范围、清理全靠手动，漏一步就内存泄漏。
立即学习“前端免费学习笔记（深入）”；
- 动画开始前 1 帧加：
element.style.willChange = 'transform'; - 必须监听
transitionend或animationend，且设回'auto'（不是空字符串） - 如果动画被中断（比如用户快速 hover 多次），
transitionend不触发，图层就永远卡住 - 滚动容器里误给子项加：
.list-item { will-change: transform; }→ 100 条 = 100 个常驻图层，DevTools Layers 面板立刻爆红
验证你是否已掉坑里的三个硬指标
别信“感觉流畅”，只看 DevTools 里真实数据：
- 打开
More Tools → Layers，筛选内存 >2MB 的图层，点开看是不是批量渲染的 item 或弹窗 - 勾选
Rendering → «Paint flashing»，滚动时满屏绿色闪动 → 说明重绘失控，will-change没起效反而加重负担 - Performance 面板录制滚动过程，
GPU Memory曲线持续爬升不回落 → 图层没释放，Android/iOS 崩溃前兆
最易被忽略的一点：will-change 本身不节省 CPU 时间，它只换来 GPU 内存开销；只有当你已确认某元素在做纯 transform/opacity 动画、且帧率实测低于 55fps 时，才值得引入，并必须配 JS 动态控制生命周期。
