will-change 仅对 transform、opacity、scroll-position、contents 四个值有效，且需配合对应动画；静态声明易致内存泄漏和卡顿，应动态设置并用双 requestAnimationFrame 清除。
will-change 不是“加了就变快”的开关，它只在你已经用 transform 或 opacity 实现动画的前提下，才可能起作用；直接给 left、width、background-color 加 will-change，浏览器会忽略，甚至拖慢性能。
哪些值真正被浏览器识别并触发图层提升
主流浏览器（Chrome 98+、Safari 16.4+、Edge 114+）只对以下四个值实际响应并创建合成层：
-
transform（含translate、scale、rotate等） -
opacity（需明显变化，如0 → 1，微调如0.99 → 1通常不触发） -
scroll-position（仅对滚动容器有效，但 iOS Safari 完全不支持） -
contents（语义弱，且会透传到子元素，慎用）
其余所有值，比如 will-change: left、will-change: width、will-change: all，在现代浏览器中要么被忽略，要么触发无效预分配，还可能干扰真实动画的分层时机。
为什么写死在 CSS 里反而更卡
静态声明如 .item { will-change: transform; } 等于让所有匹配元素长期驻留 GPU 图层，带来三重代价：
立即学习“前端免费学习笔记（深入）”；
- GPU 内存持续上涨，一屏 20 个列表项就可能吃掉几十 MB 显存
- iOS Safari 图层管理保守，常驻图层易引发白屏或滚动卡死
- 中低端安卓机图层超 5～8 个后，纹理上传开始阻塞，帧率断崖下跌
Chrome DevTools 的 Layers 面板里若看到大量 Reason 标为 will-change 的图层，基本就是滥用信号。
动态设置 + 双 requestAnimationFrame 清除才是安全做法
必须由 JS 控制生命周期，且清除动作不能靠 setTimeout 猜时长：
- 动画开始前 1～2 帧设：
element.style.willChange = 'transform'; - 监听
transitionend或animationend事件 - 清除必须用双
requestAnimationFrame：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 避免父容器和子元素同时设
will-change——图层嵌套会放大开销
第一层进下一渲染帧，第二层确保该帧已完成绘制、图层已稳定参与合成；少一层，就可能闪屏或内存泄漏。
验证是否真生效，别信“看起来顺”
打开 Chrome DevTools → More Tools → Layers 面板，手动触发动画或滚动：
- 目标元素出现在图层列表中，且
Reason字段显示layer-for-transform或layer-for-opacity，才算真正升层 - 若
Reason是will-change，仅代表提示收到，不代表已执行优化 - 勾选 Rendering 面板中的 «Paint flashing»：满屏绿色闪动，说明
will-change泛滥了
最常被忽略的一点：will-change 本身不节省 CPU 时间，反而增加 GPU 内存开销；它只是高代价的预分配指令，只有当你确认后续确实变更了 transform 或 opacity，且该元素已是性能瓶颈时，才值得引入并精细管理。
