低端安卓机型上HTML页面滚动卡顿的结构化成因分析与修复

滚动卡顿的四大主因是：未触发硬件加速（需同时加-webkit-overflow-scrolling: touch和transform: translateZ(0)）、touchmove监听器未设passive: true、scroll中读取layout触发强制同步布局、长列表未做虚拟滚动；任一缺失均导致帧率不稳。

滚动卡顿是因为 overflow: scroll 没触发硬件加速

低端安卓 WebView 默认把 overflow: scroll 容器当普通 DOM 处理，走 CPU 软件合成，帧率掉到 20–30fps。这不是代码写错了，是浏览器没被明确告知“这个区域要 GPU 渲染”。

必须同时加两行 CSS 才生效：
- -webkit-overflow-scrolling: touch（iOS 必开，安卓 WebView 也认）
- transform: translateZ(0)（强制创建独立合成层）

只加其中一条，尤其只加 translateZ(0)，在多数中低端安卓机上仍卡顿。

touchmove 监听器让原生滚动降级为 JS 驱动

只要给滚动容器绑了 touchmove，哪怕回调里只写了 console.log()，iOS 和很多安卓 WebView 就会禁用原生滚动优化——变成每帧都调 JS，一卡一卡。

修复方式很简单但常被忽略：
- 必须显式传 { passive: true }：element.addEventListener('touchmove', handler, { passive: true })
- 绝对不要在回调里调 preventDefault()，否则 passive: true 失效
- 如果真需要拦截滚动（比如下拉刷新），改用 touchstart + touchmove 组合，并只在必要时设 passive: false

scroll 事件里读 layout 信息直接掉帧

在 scroll 回调里调 getBoundingClientRect()、offsetHeight 或任何带“获取”字眼的 API，都会触发强制同步布局（forced synchronous layout），浏览器必须立刻重算整个页面流，单次耗时轻松超 10ms，直接导致掉帧。

可行替代方案：
- 把 layout 读取移到 requestIdleCallback() 或节流后的回调末尾
- 用 IntersectionObserver 替代手动计算元素位置
- 真要实时读，先缓存一次值，后续滚动中复用，直到 resize 或 orientationchange 再更新
- 改用 transform: translateY() 移动元素，它不触发 layout，只走合成层

长列表未做虚拟滚动，DOM 数量压垮渲染线程

超过 200 行的列表，哪怕所有 CSS 和事件都优化到位，低端安卓机仍会卡——不是逻辑慢，是内存和 DOM 树遍历成本太高。

虚拟滚动不是“可选优化”，是硬性需求：
- 只渲染视口内 + 上下各 1–2 屏的节点（通常 ≤ 20 条）
- 用一个 div 占位撑起总高度：style="height: calc(var(--item-height) * var(--total-count))"
- 滚动时仅更新 scrollTop 和当前渲染索引，不增删 DOM
- 不要用 will-change: scroll-position 试图“骗”浏览器优化，旧版 WebView 不支持，新版反而增加内存开销

立即学习“前端免费学习笔记（深入）”；

真正卡住低端安卓机的，往往不是某一行 JS 写得不好，而是多个看似独立的优化点都没打穿：合成层没建、事件没设 passive、layout 读取没节流、DOM 没裁剪。四个点漏掉任意一个，帧率就稳不住。