如何用虚拟列表配合 IntersectionObserver 渲染百万级 DOM 节点

IntersectionObserver 不能替代 scroll 事件实现虚拟列表——它不提供滚动偏移量，无法精确计算 startIndex/endIndex，强行使用会导致卡顿、白屏、索引跳变；正确做法是 scroll + scrollTop 计算核心逻辑，IntersectionObserver 仅用于缓冲区外资源预加载。

IntersectionObserver 不能直接替代滚动计算

很多人一看到“懒加载”“可视区域判断”，就下意识想用 IntersectionObserver 替代 scroll 事件来驱动虚拟列表。这是错的——IntersectionObserver 不提供滚动偏移量，无法实时、精确地算出 startIndex 和 endIndex。它只告诉你“某个元素进/出了视口”，但不告诉你“现在滚到了第几行”。强行用它做虚拟列表，会导致：滚动卡顿、白屏闪烁、索引跳变、缓冲区失效。

正确分工是：IntersectionObserver 做「辅助加载」，比如图片懒加载、组件异步初始化；而虚拟列表的核心滚动逻辑，必须依赖 scroll 事件 + scrollTop 计算，或用 requestAnimationFrame 节流后的滚动监听。

固定高度场景下，IntersectionObserver 可用于预加载缓冲区外的节点

在已知 itemHeight 的前提下，虚拟列表通常会渲染 startIndex - buffer 到 endIndex + buffer 的范围（比如上下各多 5 条）。这部分缓冲区之外的节点，可以交给 IntersectionObserver 提前感知并预加载资源（如图片、图标字体、远程数据），但不参与 DOM 渲染。

• 把缓冲区边界外的“占位 div”设为观察目标，threshold 设为 0，rootMargin 设为 "500px"（略大于缓冲距离）
• 一旦触发 isIntersecting，调用 fetchImage(item.id) 或标记该条目为“待激活”
• 注意：不要在回调里直接 setState 触发重渲染，否则会破坏虚拟列表的 DOM 复用逻辑
• 避免对每个 item 都新建一个 IntersectionObserver 实例——复用同一个 observer 实例观察多个目标

滚动监听必须用节流 + requestAnimationFrame

原生 scroll 事件每秒可触发 60–120 次，直接绑定会导致严重性能抖动，尤其在移动端。不加节流的代码会让 handleScroll 反复读取 scrollTop、反复计算索引、反复调用 renderList()，最终触发 Layout Thrashing。

• 必须用 requestAnimationFrame 包裹滚动处理逻辑，确保每帧最多执行一次
• 不要在 handleScroll 里直接操作 DOM 或调用 innerHTML = '' —— 改用 DocumentFragment 批量插入
• 容器需显式设置 style.overflow = 'auto' 和固定 height，否则 clientHeight 和 scrollTop 行为不可靠
• 若使用 transform: translateY() 定位内容区，确保父容器有 will-change: transform 提示浏览器开启 GPU 加速

百万级数据不能全塞进内存，得配合分页或游标加载

哪怕虚拟列表只渲染几十个节点，如果原始数据是 100 万条 JSON，全量加载到 JS 内存中也会导致 V8 堆内存暴涨（轻松超 200MB），引发 GC 卡顿甚至崩溃。这不是渲染问题，而是数据加载策略问题。

• 前端永远不该一次性请求 100 万条记录——后端必须支持基于游标（cursor）或时间戳的增量拉取
• 虚拟列表的 totalItems 可设为服务端返回的预估总数（如 X-Total-Count: 982341），但本地只维护当前窗口前后若干页的数据缓存
• 滚动接近底部时，用 IntersectionObserver 观察最后一个渲染项，触发下一页 fetch，再合并进本地缓存（注意去重和索引偏移）
• 长期滚动后，考虑按需释放远端缓存（例如只保留最近 3 页），避免内存持续增长

真正卡住百万级列表的，往往不是“怎么渲染”，而是“怎么不让数据把内存撑爆”和“怎么让滚动位置不漂移”。IntersectionObserver 在这里只是配角，别让它扛主戏。