直接监听 scroll 易卡顿因触发频率过高导致重排重绘，应改用 IntersectionObserver 实现触底加载，配合 cursor 分页与 AbortController 避免状态混乱。

为什么直接监听 scroll 容易卡顿？

因为原生 scroll 事件触发频率极高（每毫秒都可能触发），若在回调里直接调用 fetch 或操作 DOM，浏览器会频繁重排重绘，导致掉帧。尤其在低端设备或列表项含图片/复杂样式时，scrollTop 检查 + appendChild 组合极易引发 Layout Thrashing。

关键不是“要不要监听”，而是“什么时候响应”。必须加节流或采用更稳定的检测方式：

• 用 IntersectionObserver 替代 scroll + 手动计算 —— 它由浏览器原生调度，不阻塞主线程
• 若必须用 scroll，至少用 requestIdleCallback 或 setTimeout(..., 0) 延迟到空闲期执行加载逻辑
• 避免在滚动中反复读取 document.documentElement.scrollHeight 和 scrollTop，这些是强制同步布局的“脏读”

怎么用 IntersectionObserver 实现可靠触底加载？

它不依赖滚动位置数值，而是观察一个“占位元素”（sentinel）是否进入视口。只要它一出现，就说明该加载下一页了。这种方式对虚拟滚动、动态高度、甚至 CSS transform 位移都兼容。

注意三个易错点：

立即学习“Java免费学习笔记（深入）”；

• rootMargin 要设为类似 "0px 0px 200px 0px"，提前 200px 触发，避免用户已看到空白才开始请求
• 观察器创建后，必须确保 sentinel 元素真实存在于 DOM 中；若用 React/Vue 动态渲染，需在节点挂载后再 observe()
• 加载中要 unobserve(sentinel)，防止重复触发；新数据追加后，再 observe() 新的 sentinel

const observer = new IntersectionObserver(
  (entries) => {
    if (entries[0].isIntersecting && !loading) {
      observer.unobserve(sentinel);
      loadMore().finally(() => observer.observe(sentinel));
    }
  },
  { rootMargin: "0px 0px 200px 0px" }
);
observer.observe(sentinel);

长列表卡顿的真正瓶颈往往不在 JS，而在 DOM 节点数量

渲染 1 万条