移动端滑动卡顿根本原因是滚动容器内元素触发强制重排，而非单纯未开启GPU加速；必须避免在滚动中修改top/left/width/height/margin等布局属性，统一使用transform定位，并动态管控will-change以确保合成层有效。
移动端滑动卡顿根本不是“没开GPU加速”，而是滚动容器触发了重排
滑动卡顿最常见原因，是给 overflow: scroll 的容器加了 top、left、width、height 或 margin 动画——这些属性一变，浏览器必须重算整个布局树，主线程瞬间堵死。iOS 和 Android 5–7 的 WebView 尤其敏感，哪怕只是 transform: translateY() 混了 margin-top，整段滚动就退回到 CPU 渲染。
- 只对滚动容器本身做
transform位移（如轮播图外层平移），别在子项上同时改left和transform - 禁用
transition: all；明确只写transition: transform 0.3s或transition: opacity 0.2s - 避免在滚动中动态修改
width/height：缩放用transform: scale()，隐藏用opacity: 0+visibility: hidden（非display: none）
为什么 -webkit-overflow-scrolling: touch 必须配合 transform 隔离
-webkit-overflow-scrolling: touch 确实能启用 iOS 原生滚动线程，但它不解决“滚动时内容还在重排”的问题。如果滚动区域内的元素自身用了 top 或 calc() 嵌套定位，GPU 合成层会被打断，滚动帧率照样掉到 30fps 以下。
- 滚动容器（如
.scroller）设-webkit-overflow-scrolling: touch，同时加transform: translateZ(0)强制升层 - 容器内所有可动画子项，统一用
transform: translateX()/translateY()定位，彻底剔除top、left、margin - 慎用
will-change: scroll-position：它基本无效，且可能引发 iOS 滚动回弹异常
will-change 不是开关，是“临门一脚”的提示信号
把 will-change: transform 写死在 CSS 里，等于让浏览器为每个滚动项长期分配 GPU 内存。一屏 20 个列表项，就是 20 个常驻合成层，低端安卓机内存飙升、滚动卡顿反而更严重。
- 只在用户手指真正开始拖拽时（
touchstart或pointerdown）动态设置：element.style.willChange = 'transform' - 滚动结束（监听
scrollend事件，或降级用setTimeout延迟 100ms）立刻清除：element.style.willChange = 'auto' - 绝对不要对静态导航栏、页脚等不滚动的区域加
will-change
验证是否真加速：别信代码，看 DevTools 的橙色边框
写了 transform、加了 will-change，不代表 GPU 加速生效。Chrome / Safari DevTools 的 “Layer borders” 才是唯一可信依据。
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools →
Cmd+Shift+P输入Rendering→ 勾选Layer borders - 正常情况：滚动容器和动画元素周围出现**细橙色边框**，表示已进入独立合成层
- 异常情况：橙色边框闪烁、消失，或边框包裹了整页（说明图层爆炸），此时要检查是否有
filter、backdrop-filter或未清理的will-change - 配合
FPS meter实时观察：稳定在 55–60fps 才算达标，低于 45fps 仍需排查
transform: translate3d(0, 0, 0) 在旧版 WebView 中有效，但在 iOS 16+ 可能导致字体渲染模糊；又比如 contain: layout paint 能隔离重排影响，但部分安卓机型不支持。动手前先看目标设备的渲染能力，比堆技巧更重要。 
