加了 will-change 反而更卡，是因为它滥用导致图层失控、GPU内存耗尽；仅当JS驱动动画、首帧延迟>16ms且未被自动升层时，才需动态设置并及时清理。
加了 will-change 反而更卡，基本是因为图层失控——它不是“动画加速开关”，而是向浏览器申请提前创建合成图层的提示，用错时机、对象或不清理，就会吃光 GPU 内存、拖垮帧率。
为什么加了 will-change: transform 更卡
浏览器一看到 will-change: transform，立刻做三件事：为该元素新建独立合成图层、预分配 GPU 显存、上传纹理。但若这个元素根本没动，或只动 100ms 就停，这些资源就全白占着。
- 中低端安卓机图层数超 5～8 个后，纹理上传开始阻塞，
FPS从 60 掉到 20 是常态 - iOS Safari 更敏感，常驻图层过多可能直接白屏或合成器中断
-
overflow-x: auto容器加了will-change完全无效，原生滚动不走合成线程 - 元素带
border-radius或overflow: hidden，还会强制回退软件渲染，will-change彻底失效
什么情况下才值得动态加 will-change
仅当同时满足以下三个条件时，才考虑在 JS 中临时设置：
- 动画由 JS 驱动（比如在
touchmove中实时更新element.style.transform），不是靠transition或原生滚动 - 已用 DevTools Performance 面板确认首帧延迟 > 16ms，且 Layers 面板里该元素没绿色边框（说明未被自动升层）
- 该元素当前确实没被浏览器自动提层（比如没配
transform: translateZ(0)）
此时可在 touchstart 阶段设：element.style.willChange = 'transform'，并在 touchend 或 transitionend 后立刻设回 'auto'。iOS Safari 有时不触发 transitionend，建议加 setTimeout(() => el.style.willChange = 'auto', 350) 兜底。
立即学习“前端免费学习笔记（深入）”；
比 will-change 更稳、更常用的替代方案
绝大多数复杂动画根本不需要 will-change，这些方式更可控、兼容性更好：
- 用
transform: translateZ(0)或transform: translate3d(0, 0, 0)显式触发图层提升，无需 JS 生命周期管理 - 确保
transition写在基础状态上（如.card-list { transition: transform 0.3s ease; }），而不是只写在开启动态类里 - 绝对禁止在滚动/动画回调里读取
scrollTop、offsetHeight或getComputedStyle()—— 即使一次也会打断渲染流水线 - 动画属性只用
transform和opacity；避免left、width、filter（尤其模糊）等高开销属性
真正容易被忽略的是：will-change 的生效前提是「浏览器能静态预判变化」。一旦动画依赖 vw、rem、resize 或运行时计算值，它就完全失效——这时候卡顿根源在 Layout，不是合成。
