移动端滚动卡顿主因是双击延迟、抑制合成的CSS及JS同步读布局，而非缺硬件加速；应优先设touch-action启用原生滚动，动态添加will-change，并避免禁用GPU合成的CSS组合。
移动端滚动卡顿不是“没开硬件加速”，而是原生滚动根本不用它
给 .scroll-container 加 transform: translateZ(0) 或 will-change: transform，不仅不能提升滚动流畅度，反而会让 iOS Safari 14 以下和多数 Android WebView 更卡。原因很简单：原生滚动（scrollTop/scrollTo）走的是浏览器的合成器滚动管线，不依赖 transform 渲染路径；你强行建层，只是让 GPU 空转占显存，CPU 仍要满负荷算 layout 和 paint。
真正卡顿的根源是三件事叠加：
– 浏览器默认等待 300ms 判定是否双击，导致 touchmove 延迟触发
– 滚动容器或子元素带抑制合成的 CSS（如 overflow: hidden + border-radius）
– 主线程被 JS 同步读取布局（如 offsetHeight、getBoundingClientRect()）阻塞
touch-action 才是开启流畅滚动的第一把钥匙
必须在可滚动容器上明确声明手势意图，否则浏览器不敢跳过双击判定逻辑。touch-action: pan-y（纵向）或 touch-action: pan-x（横向）才能让 touchmove 立即响应，这是所有后续优化的前提。
- 禁止写
touch-action: none，除非你 100% 自己接管所有手势（包括点击穿透） - 子元素如有可点击区域（如卡片、按钮），需单独加
touch-action: manipulation，否则点击失效 -
touch-action不继承，父设了不等于子自动生效 - iOS 上若用
100vh设容器高度，地址栏收起时视口变化会导致touch-action失效；应改用100dvh或 JS fallback
动态 will-change 只作用于正在位移的子元素
静态给整个列表容器加 will-change: transform 是最常见错误——它会让所有子项提前升层，内存暴涨，低端机直接掉帧。真正该做的，是在滚动开始时，只对那个「正在被 touchmove 驱动的子容器」（比如 .list-content）临时设置：
立即学习“前端免费学习笔记（深入）”；
-
touchstart或首个touchmove时：el.style.willChange = 'transform' -
touchend后setTimeout(..., 100)：立刻执行el.style.removeProperty('will-change') - 若用
transform: translateY()模拟滚动，才需要配will-change；纯overflow: auto滚动不需要 - 滚动结束 100ms 是经验值：太短可能误判惯性未停，太长会白占图层
这些 CSS 组合会让所有优化归零
即使 touch-action 和动态 will-change 都写对了，只要存在以下任一组合，浏览器就会强制回退到 CPU 渲染，GPU 层直接失效：
-
overflow: hidden+border-radius（iOS Safari 禁用 GPU 合成圆角） - 父容器有
opacity: 0.99或filter: blur(1px)（压制子元素提层） - 滚动区域用了
scroll-behavior: smooth（与 JSscrollTo冲突，导致合成层反复切换） - 同时用了
-webkit-overflow-scrolling: touch和will-change（旧 iOS 下二者互斥，优先保留前者）
最容易被忽略的一点：硬件加速从来不是“越早加越好”，而是“刚好在动的时候加、刚停就撤”。多一层合成层，就多一分显存压力；而滚动性能瓶颈，往往卡在内存带宽而非计算能力上。
