will-change 应仅对将频繁变化且能触发合成的 transform、opacity 属性声明；避免滥用如 all、left、top 等无效属性，须动态添加/移除，慎用于滚动容器，移动端需兼顾兼容性与内存限制。
will-change 该提前声明哪些属性
声明太多或错的属性，浏览器会白开硬件加速图层，吃内存还拖慢渲染。真正该声明的只有那些即将在 transition 或 animation 中频繁变化、且能触发合成（compositing）的属性：比如 transform、opacity。其他如 width、height、top、left 基本无效，甚至可能强制重排，得不偿失。
常见误用：will-change: all 或 will-change: left, top, background-color —— 这些几乎从不触发合成，纯属浪费资源。
-
transform和opacity是安全且有效的组合，尤其适合滑动菜单、模态框淡入、卡片翻转 - 如果只动
transform，就只写will-change: transform；加了透明度过渡，再补上opacity - 避免在父容器上声明
will-change却让子元素做动画——浏览器可能无法精准提升子元素图层，反而失效
什么时候加、什么时候删 will-change
它不是 CSS 开关，而是运行时提示。长期挂着 will-change 会让浏览器一直维持额外图层，移动端内存紧张时极易引发卡顿甚至崩溃。必须动态控制生命周期。
典型错误：页面一加载就在元素上写死 will-change: transform，然后整个生命周期都不动它。
立即学习“前端免费学习笔记（深入）”；
- 在用户交互触发前（比如
touchstart或mouseenter）才添加will-change类或内联样式 - 动画结束后（监听
transitionend或animationend）立刻移除，别等下一次 - 滚动场景慎用：不要给
scroll容器设will-change，更不要监听scroll频繁 toggle —— 这比动画还容易掉帧
移动端 Safari 和 Chrome 的兼容性差异
iOS Safari 对 will-change 更敏感，也更容易因滥用导致内存暴涨；Android Chrome（尤其旧版）则可能完全忽略某些声明，或对 transform 提升不及时。
真实报错虽少，但表现诡异：比如动画突然卡住一帧、元素闪烁、返回上一页后页面白屏 —— 很可能就是 will-change 图层没正确释放。
- iOS 15+ 支持完整，但建议配合
transform: translateZ(0)降级兜底（仅当will-change不可用时） - Android Chrome 80+ 行为较稳定，但低端机仍建议限制同时激活的
will-change元素不超过 2–3 个 - 永远用
getComputedStyle(el).willChange检查是否生效，别只看写了没写
替代方案比硬上 will-change 更可靠
很多场景下，will-change 是“治标”，而改结构或换实现才是“治本”。尤其在移动端，过度依赖它反而掩盖了更严重的布局问题。
比如轮播图卡顿，第一反应不该是加 will-change: transform，而是先看是否每张图都套了 position: relative + z-index，是否用了 box-shadow 或 border-radius 在动画元素上——这些都会阻止合成。
- 优先用
transform+opacity实现位移/缩放/淡入，避免触发布局（layout）和绘制（paint） - 把动画元素单独提一层（
isolation: isolate或包一层空div），减少层叠上下文干扰 - 真要性能压榨，用
requestAnimationFrame手写关键帧，比全靠 CSS 动画 +will-change更可控
will-change 是个窄口子提示，不是性能银弹。它起效的前提，是你的动画本身已经跑在合成层路径上——否则加了也白加，还埋了坑。
