低端安卓机型滚动卡顿主因是html结构引发软件渲染+同步布局+过度重绘三重叠加，嵌套超6层拖慢fcp，需精简dom、启用硬件加速、设passive监听、实施虚拟滚动。
低端安卓机型上滚动卡顿，八成不是 JS 慢，而是 HTML 结构本身触发了软件渲染路径 + 强制同步布局 + 过度重绘三重叠加。
嵌套过深（>6 层）直接拖慢首次内容绘制
浏览器解析
<div><div><div><div><div><div><p></p></div></div></div></div></div></div> 时，每层都要创建 DOM 节点、匹配样式、计算布局。在骁龙 425 或联发科 MT6737 这类芯片上，FCP 延迟常超 200ms，滚动前页面都还没 ready。
- 用 Chrome DevTools → Elements 面板右键节点 →
Show DOM properties 查 <code>depth值，>6 就必须拆 - 能用
<section></section>、<header></header>、<article></article>替代三层<div> 堆叠的，优先替换——语义标签不提速，但 DOM 节点数少、样式匹配快 <li><code><td> 里别套 <code><div>：表格单元格内样式计算成本高，嵌套后极易触发重排，尤其和 flex 容器混用时 <h3>overflow: scroll 容器没激活硬件加速</h3> <p>只写 <code>overflow-y: auto不够，安卓 WebView 默认走软件合成，帧率掉到 20–30fps。必须显式告诉浏览器：“这个区域要 GPU 渲染”。- 滚动容器必须加
-webkit-overflow-scrolling: touch（iOS 必需）+transform: translateZ(0)（安卓必需） - 别用
will-change: scroll-position替代——它在 Android 8.0 以下 WebView 中基本无效 - 如果容器高度靠 JS 动态设置，确保 CSS 生效时
height已确定，否则合成层会被降级 - 原生 Android App 中的 WebView 还得检查 Java 层：
webView.setLayerType(View.LAYER_TYPE_HARDWARE, null)，不能留android:layerType="software"
scroll 事件监听器阻塞主线程
只要给滚动容器绑了
touchmove或未设passive: true的scroll监听器，iOS 和多数安卓 WebView 就会禁用原生滚动优化，变成逐帧 JS 驱动。- 错误写法：
element.addEventListener('scroll', handler)—— 缺少{ passive: true } - 正确写法：
window.addEventListener('scroll', handleScroll, { passive: true }) - 若真要阻止默认行为（如下拉刷新），改用
touchstart+touchmove，并显式传{ passive: false } - 滚动回调里禁止调用
getBoundingClientRect()、offsetTop等触发强制同步布局的 API；读布局信息必须节流或移到requestIdleCallback
长列表没做虚拟滚动，DOM 节点爆炸
列表项超 200 行时，哪怕所有 CSS 和事件都优化到位，DOM 节点过多仍会让低端机内存吃紧、垃圾回收频繁、帧率跌破 30fps。
- 必须放弃一次性渲染全部数据，只渲染视口内 + 上下各 1~2 屏的节点（缓冲区）
- 用精确
height占位撑起整体列表高度，避免滚动条跳变 - 监听
scroll只更新当前起始索引和scrollTop，不新增/删除 DOM 节点 - 手写方案注意：别用
innerHTML +=拼接，每次重写都会触发完整重排；用DocumentFragment批量插入
真正卡顿的点，往往藏在看似无害的嵌套结构和默认 CSS 行为里——比如一个没加
translateZ(0)的overflow-y: scroll容器，或表格单元格里多套的一层<div>，在高端机上毫无感知，在骁龙 439 上就是卡顿源头。</div> - 滚动容器必须加
