will-change 对原生 overflow: scroll 完全无效且易致卡顿，仅在 JS/CSS transform 驱动的模拟滚动中有效，且须严格配合 touchstart/touchend 动态开关；替代方案如 translateZ(0)、passive 滚动监听、虚拟列表更稳定可靠。
will-change 对原生响应式滑屏（overflow: scroll）完全无效，加了反而更容易卡顿；它只在 JS 或 CSS transform 驱动的模拟滚动中起作用，且必须配合生命周期管理——否则内存泄漏、图层堆积、帧率暴跌是常态。
为什么给 scroll-container 加 will-change: transform 更卡
浏览器看到 will-change: transform，会立刻为该元素创建独立合成图层、预分配 GPU 内存、上传纹理。但原生滚动容器（如 .scroll-container { overflow-y: auto; }）本身不依赖 transform 变化，这个图层就成空转资源：
- 中低端安卓机图层数超 5～8 个后，纹理上传开始阻塞，帧率从 60fps 掉到 20fps
- iOS Safari 更敏感，常驻图层过多可能直接白屏或合成器中断
- 若容器带
border-radius或overflow: hidden，还会强制回退软件渲染，will-change彻底失效 - 初始状态是
display: none或visibility: hidden时，will-change根本不生效
will-change 只在 JS 驱动的模拟滚动中有效，且必须动态开关
仅当同时满足以下三个条件时，才值得在 JS 中临时设置：
- 滑动不是靠原生
overflow，而是由 JS 在touchmove中实时更新element.style.transform - 已用 DevTools Performance 面板确认首帧延迟 > 16ms，且瓶颈在图层未提升（Layers 面板里没绿色边框）
- 该元素当前确实没被浏览器自动升层（比如没配
transform: translateZ(0)）
此时可在 touchstart 阶段设：element.style.willChange = 'transform'，并在 touchend 或 transitionend 后立刻设回 'auto'。
立即学习“前端免费学习笔记（深入）”；
比 will-change 更稳、更常用的替代方案
绝大多数移动端滑屏根本不需要 will-change，这些方式更可控、兼容性更好：
- 用
transform: translateZ(0)或transform: translate3d(0, 0, 0)显式触发图层提升，无需 JS 生命周期管理 - 确保
transition写在基础状态上（如.sidebar { transition: transform 0.3s ease; }），而不是只写在开启动态类里 - 滚动监听必须带
{ passive: true }；绝对禁止在scroll回调里读取scrollTop或getBoundingClientRect() - 图片必须设宽高 +
loading="lazy"；长列表优先用react-window或vue-virtual-scroller
真正容易被忽略的点是：will-change 不是渲染加速器，它是图层资源的预约指令。预约早了浪费，预约错了失效，预约多了拖垮整页——而滑屏这种高频交互场景，图层生命周期管理稍有疏漏，就会在线上持续泄漏内存。
