will-change 对原生 overflow 滚动无效且易致卡顿；仅当 JS 驱动 transform 动画、首帧延迟超 16ms 且未自动升层时，才宜在 touchstart 动态启用并及时清除。
will-change 对原生 overflow 滚动完全无效，加了反而更容易卡顿；它只在 JS 驱动的 transform 动画中配合 touchstart/touchend 动态启用才可能起效。
为什么给滑动容器加 will-change: transform 更卡
浏览器看到 will-change: transform 会立刻为该元素创建独立合成图层、预分配 GPU 内存、上传纹理。但如果你的滑动走的是原生 overflow-x: auto 或 scrollTop，这个图层就成空转资源：
- 中低端安卓机图层数超 5～8 个后，纹理上传开始阻塞，帧率从 60fps 掉到 20fps
- iOS Safari 更敏感，常驻图层过多可能直接白屏或合成器中断
- 若容器带
border-radius或overflow: hidden，还会强制回退软件渲染，will-change彻底失效 - 初始状态是
display: none或visibility: hidden时，will-change根本不生效
什么情况下才值得 JS 动态设置 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写在基础状态上（如.slider { transition: transform 0.3s ease; }），而不是只写在开启动态类里 - 给可滚动容器设
touch-action: pan-x（横向）或pan-y（纵向），禁止none除非你完全接管手势 - 避免在滑动中读取
offsetLeft、getBoundingClientRect()等强制同步 layout 的 API
真正容易被忽略的是：will-change 不是渲染加速器，它是图层资源的预约指令——预约早了浪费，预约错了失效，预约多了拖垮整页；而 Layer borders（DevTools → Rendering → Layer borders）才是唯一能验证是否真提层的标准。
