will-change 应加在真正要动画的元素本身，仅对即将变化的属性声明，JS 动态添加并及时移除；移动端需检测支持、限制数量、避开 fixed 元素；它非银弹，不解决 layout thrashing 等根本问题。
will-change 该在什么元素上加
加在真正要动画的元素本身，不是父容器，也不是过渡中的中间节点。浏览器只对 will-change 声明的元素做图层提升和渲染预热，加错位置等于白配。
常见错误现象：transform 动画仍有卡顿，DevTools 的 Layers 面板里看不到新合成层；或者页面内存占用明显升高，但动画没变顺。
- 只对即将变化的属性声明，比如只做
transform就写will-change: transform，别写will-change: all - 避免提前全局声明：不要在 CSS 文件里给所有
.card都加will-change，而应在 JS 触发动画前动态添加 class 或内联样式 - 动画结束后及时移除：用
transitionend或animationend事件清理，否则图层长期驻留，拖慢滚动和后续动画
移动端加了 will-change 反而更卡怎么办
因为低端 Android 设备（尤其 Chrome 80 以前）对 will-change 的图层管理不成熟，盲目提升图层会挤占 GPU 内存，导致纹理丢弃、频繁重绘。
使用场景：你正在调试一个在 iPhone 上流畅、但在红米 Note 9 上掉帧的轮播组件。
立即学习“前端免费学习笔记（深入）”；
- 先检测硬件支持：用
CSS.supports('will-change', 'transform')判断，不支持就跳过 - 限制图层数量：同一时间最多激活 2–3 个
will-change元素，轮播场景下只预热当前页和左右相邻页 - 避开
position: fixed元素：这类元素在部分安卓 WebView 中与will-change冲突，容易触发全屏重绘
will-change 和 translateZ(0) 的区别在哪
translateZ(0) 是“土办法”强制创建合成层，will-change 是标准声明式提示，两者都可能触发图层提升，但行为逻辑完全不同。
性能影响：滥用 translateZ(0) 会让浏览器持续维持图层，而 will-change 至少提供了生命周期控制入口。
-
translateZ(0)是 hack，无语义，无法被浏览器优化或忽略；will-change是提示，浏览器可选择忽略（如资源紧张时） -
translateZ(0)必须写在样式里，静态生效；will-change推荐 JS 动态控制，更贴合真实动画周期 - 现代 Chrome/Firefox 对
will-change的优化已较成熟，但 Safari 15.4 之前对will-change: opacity支持不完整，需实测
动画开始前多久加 will-change 才有效
太早加（比如页面加载时）没意义，太晚加（比如 click 回调末尾）来不及预热。理想时机是用户交互发生后、动画帧触发前的 1–2 帧。
示例：点击按钮后 16ms 内（即下一个 requestAnimationFrame 前）设置 will-change，能覆盖大部分设备的图层准备耗时。
- 不要在
mouseenter立即加，防误触；建议加个 50ms 延迟，或结合pointerdown+pointerup判断真实意图 - 用
getComputedStyle(el).willChange检查是否已生效，避免重复设置 - 如果动画由 CSS
@keyframes驱动，且触发时机不可控（如伪类:hover），优先用 JS 监听animationstart再加，比纯 CSS 更可靠
will-change 不是性能银弹，它只解决合成层准备阶段的延迟，对 layout thrashing、长任务阻塞、过度绘制这些根本问题完全无效。 
