移动端h5长列表卡顿需从滚动容器设置、硬件加速激活、监听行为约束、虚拟滚动四方面同步优化：视口meta须规范，滚动容器需显式height和-webkit-overflow-scrolling:touch/transform:translatez(0)，scroll监听必加passive:true，超200条数据必须用虚拟滚动。
移动端 H5 长列表卡顿，本质是“渲染负担”和“滚动机制”双重失配：DOM 节点多导致重排重绘吃紧，而滚动容器没走 GPU 合成层又放大了性能损耗。视口适配只是基础，真正要解决卡顿，得从滚动容器设置、硬件加速激活、监听行为约束、以及列表渲染策略四方面同步入手。
视口配置要稳，但别只靠它
基础 meta 设置必须正确，否则后续优化全打折扣：
-
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">是底线，禁用缩放可避免布局抖动和 scroll 偏移错乱 - 不要依赖
user-scalable=no来“掩盖”滚动卡顿——它解决的是交互干扰，不是性能问题 - 视口宽度匹配设备后，滚动容器（如
.list-wrapper）必须有明确的height或max-height，否则overflow-y: scroll不生效，根本不会触发滚动线程
滚动容器必须激活硬件加速
仅写 overflow-y: scroll 不会自动上 GPU；现代浏览器需显式提示合成意图：
- iOS Safari 必须保留
-webkit-overflow-scrolling: touch（注意：不是删掉，2026 年仍有效，尤其在 iOS 17–18 稳定版中；此前说“已废弃”实为误传，Chrome 63+ 废弃不等于 Safari 废弃） - 安卓 WebView 和新版 Safari 都需要
transform: translateZ(0)或will-change: transform（仅对滚动容器本身设，绝不能加在每个列表项上） - 避免混用
transform、opacity、filter的子元素——WebKit 会无序升层，打断滚动线程 - 用 Chrome DevTools → Layers 面板确认：稳定显示 3～5 个图层为佳；若超过 8 层，立刻检查是否误加了全局
will-change
滚动监听必须加 passive: true
哪怕只监听一次 scroll，没设 { passive: true } 就等于主动放弃 60fps：
- 所有
addEventListener('scroll', handler)必须显式传该选项，否则 iOS/Safari 会阻塞滚动等待 JS 执行完 - 控制台出现
"Unable to preventDefault inside passive event listener"警告，说明你本意想阻止默认行为——那就别用scroll，改用touchstart + preventDefault()实现下拉刷新等逻辑 - 禁止在 scroll 回调里读取
scrollTop、getBoundingClientRect()或写style.top——这会强制同步回流（layout thrashing） - 替代方案：用
IntersectionObserver做可视区域判断；用requestIdleCallback延迟非关键计算
长列表必须用虚拟滚动，不是“可选”，是“必须”
当数据量超 200 条，任何 CSS/JS 微调都治标不治本。虚拟滚动把 DOM 节点数从 O(n) 降到 O(1)：
- 核心逻辑：只渲染视口内 + 上下各 1～2 屏缓冲区的节点（比如 20～40 条），其余用精确高度的空白占位
- Vue3 推荐
vue-virtual-scroller：RecycleScroller用于固定行高（性能最优），DynamicScroller用于图文混排等高度不一场景 - 关键细节：行高必须可预测（固定值或缓存尺寸），滚动时只更新
scrollTop和起始索引，不新增/删除 DOM 节点 - 注意 iOS 橡皮筋滚动：触底回弹可能重复触发加载，需结合
scrollEnd判断或节流防抖
