will-change 并非万能开关，盲目添加反而加重合成器负担导致卡顿；应仅对正在滑动的元素动态设置并及时移除，配合 touch-action 明确手势意图，优先优化 dom 结构与渲染属性。
为什么 will-change 有时反而让滑动更卡
直接给 scroll 容器加 will-change: transform，常导致 iOS Safari 卡顿、Android Chrome 掉帧。这不是 bug，而是浏览器把元素提前挪进独立图层后，反而加重了合成器负担——尤其当页面存在多个 will-change 元素或频繁触发重排时。
真正起效的前提是：该元素确实需要持续、高频的 transform 或 opacity 变化，且不伴随布局计算。移动端滑动中，只有「正在被 touchmove 驱动的元素」才符合这个条件，静态设置会白占 GPU 内存。
- 只对当前正在滑动的元素动态添加
will-change: transform，滑动结束 100ms 后移除 - 避免在父容器（如
.list-wrapper）上全局设置，优先作用于实际位移的子元素（如.list-content） - 确认该元素没有
overflow: hidden+border-radius组合，这会强制回退到软件渲染
配合 touch-action 才能释放真实性能
will-change 单独用几乎无效。iOS 和 Android 浏览器默认会对 touchmove 做事件节流和延迟判定（比如等 300ms 看是否是双击），导致手势响应滞后。必须用 touch-action: pan-y 明确告诉浏览器“这个区域只做垂直滚动”，才能跳过默认判定逻辑，让 touchmove 立即触发。
- 对可滚动容器设
touch-action: pan-y（纵向）或pan-x（横向），禁止none除非你完全接管手势 - 若容器内有按钮或可点击区域，用
touch-action: manipulation替代none，保留点击穿透能力 - 注意
touch-action不继承，子元素需单独设置（如内部卡片要点击，就得加touch-action: manipulation）
别忽略 scroll-behavior: smooth 的隐性冲突
如果页面同时用了 scroll-behavior: smooth 和手动 transform 滑动（比如用 scrollTop 或 scrollTo），浏览器可能在合成层和布局层之间反复切换，造成掉帧。硬件加速只对 CSS 动画/transform 生效，对原生滚动 API 的平滑行为无优化作用。
- 纯 CSS 滚动（如
overscroll-behavior: contain+ 原生scrollTop）无需will-change，也别加 - 若用
transform: translateY()模拟滚动，必须配合will-change: transform+touch-action，且动画帧率锁死在 60fps（用requestAnimationFrame驱动） - 禁用
scroll-behavior: smooth，改用 JS 控制 easing，否则两者叠加会导致视觉撕裂
真机调试时最该看的两个指标
Chrome DevTools 的「Rendering」面板里勾选「FPS meter」和「Paint flashing」，但这两个在真机上没用。实际要连上 Safari Web Inspector（macOS + iOS 设备），打开「Timelines」标签页，重点观察：
- 「Compositor Layers」数量：超过 5 层且持续不回收，说明
will-change泄露（没及时 remove） - 「Frame Rate」曲线是否稳定在 58–60fps：低于 50fps 且伴随「Raster」时间飙升，大概率是图层纹理过大（比如背景图未压缩）或
backface-visibility: hidden缺失
复杂列表场景下，will-change 的收益往往不如精简 DOM 深度、减少 box-shadow 和渐变背景来得实在。它只是最后一道微调手段，不是万能开关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
