移动端长列表虚拟滚动优化需协同DOM管理、滚动上下文与节点复用：固定容器高度防scrollTop异常，占位元素精准计算滚动条长度，节点池化复用避免频繁创建销毁，并节流滚动监听+事件委托提升性能。
移动端长列表配合虚拟滚动优化内存，核心不是“加个插件就完事”，而是从 DOM 管理、滚动上下文、节点复用三方面协同控制。真正起效的关键，在于让浏览器只维持几十个真实节点，同时避免高频重排和内存泄漏。
滚动容器必须设固定高度 + overflow-y: auto
移动端 WebView（尤其 iOS Safari 和 Android Chrome）对 auto 高度容器的 scrollTop 计算极不稳定——滚动时跳变、归零、甚至不触发事件。这会导致索引错乱、内容闪退、滚动条失准。
- 写死 height：比如
height: 500px或height: 80vh（确保 viewport 不缩放时生效） - 禁用父级
overflow: hidden裁剪，否则滚动事件压根不冒泡 - 若需适配不同屏幕，用 JS 动态设置：
container.style.height = window.innerHeight * 0.8 + 'px'，并在 resize 时更新
占位高度必须严格按 total × itemHeight 计算
滚动条长度由占位元素（phantom）撑开，它决定了用户拖动距离与实际位移的映射关系。算错 10px，滑到底部前就“卡住”；误差超 ±15px，就会明显“跳行”或漏数据。
- 等高场景：直接用
data.length * 48（假设每项 48px） - 变高场景别硬算：优先服务端返回预估高度字段，或前端分组折叠（如每 50 条合并为一个可展开区块）
- 表格类列表加
table-layout: fixed+ 显式列宽，防止文本撑开导致行高浮动
节点必须池化复用，禁用 createElement/removeChild
移动端内存紧张，频繁创建销毁节点会触发大量 layout 重排+样式计算，低端机 60fps 滚动直接掉到 20fps。关键不是“少建”，而是“不销毁”。
立即学习“前端免费学习笔记（深入）”；
- 用
Map缓存节点：nodePool.set(id, el)，查不到才新建 - 复用时只改内容：
el.textContent = item.text、el.dataset.id = item.id，不增删子节点 - 隐藏用
el.style.display = 'none'，不是remove()或innerHTML = '' - 所有事件必须委托到滚动容器上，用
event.target.closest('[data-item-id]')安全取目标
滚动监听必须节流 + passive: true
原生 scroll 在移动端每秒可触发上百次，不加限制等于每帧都在做 DOM 查询+索引计算+渲染，主线程瞬间饱和。
- 必须用
requestAnimationFrame节流，保证每帧最多执行一次更新 - 监听时传
{ passive: true }，否则 Chrome 强制同步执行 handler，拖垮滚动流畅度 - 起始索引用二分查找（如
sortedIndex），不用findIndex—— 10 万条数据下 O(n) 查找直接卡死
