IntersectionObserver 触底加载为什么重复触发：rootMargin、哨兵节点与去重状态

列表滚到最后一行时，页面偶尔会同时发出两次下一页请求，常见结果是重复数据、页码跳过，或者用户快速回滚后又补进一页。IntersectionObserver 本身只负责报告“进入观察区域”，不会替你合并事件；真正要稳定触底加载，必须同时控制预加载距离、哨兵节点和请求状态。

重复请求通常不是回调“失控”

IntersectionObserver 的回调可能在同一轮滚动中收到多条记录，也可能因为列表追加、哨兵重新插入和视口变化而再次执行。只要哨兵还在观察区，回调再次到达就是合理行为。问题在于业务层把每次回调都当成了“可以请求下一页”。

例如列表高度刚好接近容器底部，追加一页后旧哨兵仍在可视范围；如果代码先 append 新内容、再异步更新页码，第二次回调可能在第一次请求完成前抵达。这里别急着把 rootMargin 调小，先把请求生命周期画清楚。

rootMargin 只决定提前量，不承担去重

rootMargin: '0px 0px 320px 0px' 表示底部提前 320 像素进入观察范围。它适合给网络请求留出时间，但也会让哨兵在“用户还没真正到底部”时就触发。移动端快速滑动、内容高度变化和图片加载完成，都可能让它再次跨过阈值。

const observer = new IntersectionObserver(onIntersect, {
  root: document.querySelector('.list'),
  rootMargin: '0px 0px 320px 0px',
  threshold: 0
});

经验上，先按一次请求耗时和用户滚动速度估算提前量，再用浏览器 Network 面板核对请求间隔。把提前量改成 0 只能降低触发频率，不能替代状态判断。

回调入口先做三道检查

把判断放在请求函数内部，而不是只放在 observer 回调里，可以避免其他入口（刷新、重试按钮或初始化逻辑）绕过保护。下面的页码只有在响应成功后才推进：

let page = 1;
let isLoading = false;
let hasMore = true;

async function loadNextPage() {
  if (isLoading || !hasMore) return;

  isLoading = true;
  const nextPage = page + 1;
  try {
    const response = await fetch(`/api/items?page=${nextPage}`);
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const result = await response.json();
    appendItems(result.items);
    page = nextPage;
    hasMore = result.hasMore;
  } finally {
    isLoading = false;
  }
}

function onIntersect(entries) {
  if (entries.some(entry => entry.isIntersecting)) {
    loadNextPage();
  }
}

isLoading 是并发闸门，hasMore 是结束条件，nextPage 则避免失败时把当前页提前改掉。若接口返回空页但没有明确的结束字段，才考虑以“返回数量小于 pageSize”作为兜底规则，并在接口文档中固定下来。

哨兵节点的生命周期也要管

使用单独的末尾哨兵时，追加内容应保持它仍是列表最后一个子节点。若渲染函数每次都重建列表，旧节点可能被移除，新节点却没有重新观察；反过来，如果旧节点没有解除观察，就可能留下多个回调来源。

const sentinel = document.querySelector('#list-sentinel');
observer.observe(sentinel);

function replaceList(items) {
  list.replaceChildren(...items.map(renderItem), sentinel);
}

框架场景中，组件卸载时执行 observer.disconnect()，组件重新挂载后再 observe。不要把 observer 实例放在每次渲染都会重新执行的函数里，否则重复观察和重复清理会变得很难追。

失败、回滚与验收方法

请求失败时要释放 isLoading，但保持 page 不变，让用户可以重试同一页。成功追加后再更新页码；如果接口支持请求幂等键，可以把“列表标识 + 页码”作为请求标识，服务端也做一次保护。

验收时不要只看“滚到底能加载”。至少覆盖三种操作：快速连续滚动、慢速滚动并等待图片布局变化、请求失败后再次进入观察区。Network 面板中，同一页在一次成功响应前只能有一个进行中的请求；成功后页码连续，失败重试不应跳页。

常见问题

把 threshold 改成 1 能解决重复吗？

不能。threshold 只改变交叉比例，重复回调仍可能发生，业务层仍需状态守卫。

请求完成后要不要 unobserve？

通常不必。保留一个稳定的末尾哨兵更简单；只有在没有更多数据或组件销毁时才停止观察。

为什么加载一页后马上又请求一页？

如果新内容不足以把哨兵推离 rootMargin，第二次触发是预期结果。确认上一页已成功、状态已更新，并判断是否确实还有更多数据。

小结

触底加载的稳定性来自三层配合：rootMargin 负责提前量，哨兵节点负责观察位置，状态变量负责决定请求是否有资格发生。先在请求入口挡住并发，再处理页码提交、失败恢复和节点清理，重复请求通常就能从“偶发问题”变成可验证的状态转换。