will-change本质是强制图层预分配指令，仅transform、opacity、scroll-position三者有效且需严格匹配动画行为，静态滥用或误用于盒模型属性将导致内存暴涨与性能崩溃。
will-change 本质是图层预分配指令，不是性能开关
浏览器看到 will-change 就立刻为元素创建独立合成层（composited layer），并预分配 GPU 内存——这不是“建议”，而是强制执行。它不关心你是否真在动画，也不检查属性是否可合成，只要声明了，图层就建好、内存就占住。
常见错误现象：* { will-change: transform; } 或 .card { will-change: width; } 导致 DevTools Layers 面板爆红，滚动几秒后内存暴涨、帧率骤降，甚至 Android WebView 直接 OOM 崩溃。
- 静态写死在 CSS 中的
will-change几乎等同于内存泄漏 - 加在盒模型属性上（如
width、margin、border-radius）时，浏览器仍会建层，但该层内容每帧都要重绘，GPU 只是多搬了一次脏数据 -
will-change: contents是高危操作，会让整个子树升层，10 行文字可能拉出 20+ 图层
哪些盒模型属性加了 will-change 也完全无效
will-change 只响应能走纯合成路径的属性，而盒模型变更必然触发 layout 或 paint。以下声明全部无效：
-
will-change: width/will-change: height→ 触发重排 -
will-change: top/will-change: left→ 定位偏移需重算文档流 -
will-change: margin/will-change: padding/will-change: border→ 盒模型参数变更，布局树必须重算 -
will-change: background-color/will-change: box-shadow→ 触发重绘，无法合成
实测：100 个 .item { will-change: width; } 在低端安卓机上滚动 20 秒，内存上涨 400MB+，随后白屏。
立即学习“前端免费学习笔记（深入）”；
真正有效的属性只有三个，且必须匹配动画方式
能被 will-change 实际利用的 CSS 属性仅限以下三者，且必须严格配合对应动画行为：
-
transform：仅当动画使用translate、scale、rotate等 GPU 可加速变换；混用left或top会导致整段动画降级为 CPU 渲染 -
opacity：仅用于透明度渐变；若同时动画background-color，合成失效 -
scroll-position：极少数自定义滚动监听场景（如吸顶条），普通滚动容器无需加
注意：will-change: transform 加在 .list-item 上，100 条 = 100 个常驻图层；正确做法是加在滚动容器本身（如 .scroll-container），并配 contain: strict 或 transform: translateZ(0) 隔离边界。
动态控制比写死更危险，漏一步就内存泄漏
JS 动态设置 element.style.willChange = 'transform' 看似可控，实则极易翻车：
- 必须在动画开始前 1 帧添加，不能过早（否则图层常驻）也不能过晚（起不到预分配作用）
- 必须监听
transitionend或animationend，并设回element.style.willChange = 'auto'（不是空字符串） - 动画被中断（如快速 hover 多次）时，
transitionend不触发，图层永久卡住 - 滚动容器内误给子项加
will-change: transform，DevTools Layers 面板立刻显示大量绿色图层框，无法释放
最常被忽略的一点：现代 Chrome（98+）已默认对 transform 和 opacity 启用硬件加速，will-change 不再是“开启加速”的必要条件，而是“提前下单建图层”的高风险操作——没想清楚生命周期，就别碰它。
