will-change 对原生 overflow 滚动无效且易致卡顿，仅在 JS 驱动的 transform 动画中配合 touchstart/touchend 动态启用才有效；误用会浪费 GPU 资源、触发回退渲染或白屏。
will-change 对原生 overflow: scroll 滑动完全无效，加了反而更容易卡顿；它只在 JS 驱动的 transform 位移中起作用，且必须配合 touchstart/touchend 动态开关。
为什么给滑动容器加 will-change: transform 更卡
浏览器看到 will-change: transform，会立刻为该元素创建独立合成图层、预分配 GPU 内存、上传纹理。但卡片左右滑动若走的是原生滚动（比如 .carousel { overflow-x: auto; }），这个图层就成空转资源：
- 中低端安卓机图层数超 5～8 个后，纹理上传开始阻塞，帧率从 60fps 掉到 20fps
- iOS Safari 更敏感，常驻图层过多可能直接白屏或合成器中断
- 若容器带
border-radius或overflow: hidden，还会强制回退软件渲染，will-change彻底失效 - 初始状态是
display: none或visibility: hidden时，will-change根本不生效
什么情况下才值得动态加 will-change
仅当同时满足以下三个条件时，才考虑在 JS 中临时设置：
- 滑动不是靠原生
overflow，而是由 JS 在touchmove中实时更新element.style.transform - 已用 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; }），而不是只写在开启动态类里 - 滚动监听必须带
{ passive: true }；绝对禁止在scroll回调里读取scrollTop或getBoundingClientRect() - 图片必须设宽高 +
loading="lazy"；长列表优先用react-window或vue-virtual-scroller
最容易被忽略的是：will-change 不是渲染加速器，它是图层资源的预约指令。预约早了浪费，预约错了失效，预约多了拖垮整页——而卡片滑动这种高频交互场景，图层生命周期管理稍有松懈，就等于主动给主线程加压。
