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 在这里只是配角，别让它扛主戏。
