IntersectionObserver 观察列表底部为何重复触发

做无限滚动时，列表底部的 IntersectionObserver 反复触发，通常不是浏览器“重复执行了同一条规则”，而是观察回调本来就不是一次性事件：开始观察时可能先收到一次通知，哨兵元素在交叉与离开之间变化时还会继续收到通知。真正需要防重复的是分页请求，而不是把观察器粗暴地关掉。

为什么同一个底部节点会重复进入回调

IntersectionObserver 观察的是目标与 root 的相交状态。调用 observe() 后，即使目标此刻没有出现在视口中，也可能先收到一次初始通知；之后只要相交状态跨过 threshold，回调就可能再次运行。列表追加新卡片、图片加载改变高度、rootMargin 提前扩大观察区，都可能让底部哨兵重新满足条件。

所以，下面这种写法存在竞态：回调连续进来时，两个 fetch 都读取到旧的页码，然后同时请求同一页。

const observer = new IntersectionObserver(([entry]) => {
  // 这里只判断几何状态，没有阻止并发请求
  if (entry.isIntersecting) {
    loadNextPage();
  }
});

把“观察到”与“允许加载”拆成两个状态

更稳的模式是把哨兵当作“提示器”，把 loading 和 hasMore 当作真正的加载闸门。请求成功后先追加数据，再保存服务端返回的下一游标；请求失败则保留当前游标，方便用户重试。

const list = document.querySelector('#list');
const sentinel = document.querySelector('#list-end');
let loading = false;
let hasMore = true;
let nextCursor = null;

async function loadNextPage() {
  // 观察回调可以重复到达，但同一时间只允许一个请求
  if (loading || !hasMore) return;
  loading = true;
  observer.unobserve(sentinel);

  try {
    const query = nextCursor ? `?cursor=${encodeURIComponent(nextCursor)}` : '';
    const response = await fetch(`/api/posts${query}`);
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const page = await response.json();

    // 服务端返回的游标决定下一页，不能用当前卡片数量猜页码
    list.insertAdjacentHTML('beforeend', page.html);
    nextCursor = page.nextCursor ?? null;
    hasMore = Boolean(page.hasMore && nextCursor);
  } catch (error) {
    // 失败时保留游标，让下一次触发仍可重试同一页
    console.error('分页加载失败', error);
  } finally {
    loading = false;
    // 没有下一页时不再注册观察，避免空转回调
    if (hasMore) observer.observe(sentinel);
  }
}

const observer = new IntersectionObserver(([entry]) => {
  // isIntersecting 是触发条件，loading/hasMore 才是业务许可
  if (entry.isIntersecting) loadNextPage();
}, { root: null, rootMargin: '0px 0px 240px', threshold: 0 });

observer.observe(sentinel);

这里的关键不是把回调次数变成 1，而是让重复回调变得无害。unobserve() 是降低请求竞态的辅助动作，loading 仍然必须保留，因为网络请求可能在取消观察前已经排队，或者组件逻辑在别处再次调用加载函数。

什么时候用 unobserve、rootMargin 和 hasMore

三个参数解决的是不同层面的问题：rootMargin 调整“多早发现”，threshold 调整“相交到什么程度通知”，unobserve() 管理目标生命周期，而 hasMore 管理业务数据是否还有下一页。不要用增大 threshold 的方式代替请求状态锁。

如果观察的是内部滚动容器，root 必须是哨兵的祖先；如果使用文档视口，root: null 才是清晰的选择。rootMargin: '0px 0px 240px' 只是提前 240 像素发出信号，不能证明接口已经准备好接受下一页。

用一张检查清单收住重复触发

• 回调入口只做轻量判断，不在回调里累加页码。
• 请求发出前同步设置 loading = true，失败时不要丢失当前游标。
• 追加内容后重新观察前，确认 hasMore 和 nextCursor 已更新。
• 组件卸载时调用 observer.disconnect()，避免保留旧列表节点。
• 如果服务端不支持游标，至少让页码递增与请求去重键绑定，不能只依赖滚动次数。

常见问题

IntersectionObserver 的 callback 会只执行一次吗？

不会。初始观察和后续跨过阈值都可能产生通知；是否发起请求要由业务状态决定。

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

不能。它只改变相交比例的通知条件，布局变化或重新进入仍可能触发，重复请求仍需 loading 或请求去重。

请求失败后应该 disconnect 吗？

通常不必。保留哨兵并在失败后重新观察更方便重试；只有组件销毁或彻底结束列表时才调用 disconnect()。

把 IntersectionObserver 当成“是否接近列表底部”的传感器，再把分页状态当成唯一闸门，重复回调就不会直接变成重复数据。排查时先看请求是否并发、游标是否推进，再调整观察范围。