登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  前端

网页长列表怎么用 IntersectionObserver 只触发一次加载:观察状态、哨兵节点与并发收口

来源:17golang原创

时间:2026-08-29 23:13:47 106浏览 收藏

长列表滚到末尾时,哨兵节点可能连续几帧都处在可见区域,IntersectionObserver 于是多次进入回调。如果只判断 entry.isIntersecting 就直接请求,慢接口还没返回,下一页已经被重复拉取。可靠的做法是把 sentinelloadinghasMoreloadMore 放进同一条控制流:第一次进入时摘掉观察,完成后再观察;没有下一页时永久停止。

IntersectionObserver 负责报告“看见了哨兵”,业务状态负责决定“现在能不能加载”。先用 loading 收口并发,再用 unobserve 阻断当前批次的重复回调。

要点速览
  • 首次 observe 可能很快回调,不能把一次回调当成一次滚动。
  • loading 防止请求未结束时重复进入 loadMore
  • hasMore=false 后要 unobserve,末页不再制造无效请求。

问题出在哨兵持续可见,而不是滚动事件太多

示例页面把一个空的 sentinel 放在列表底部,列表追加下一页后它仍然靠近视口。IntersectionObserver 的回调收到 entries,每个条目的 target 都是被观察的元素;真正触发加载的条件是 entry.isIntersecting 为 true。

这里有两个容易混淆的事实。第一,调用 observe(sentinel) 后,浏览器会在后续渲染周期给出初始通知,即使元素没有移动。第二,回调数组可能一次带来多个条目。它们都说明观察状态变化,不代表服务端请求已经完成。

IntersectionObserver 观察 sentinel 后由 entry.isIntersecting 进入 loadMore 的前端控制流

用 loading 和 hasMore 把请求入口收成一个分支

先让状态变量表达业务事实,再写观察器。loading 只在 loadMore 开始到 finally 结束期间为 true;hasMore 则来自接口返回的分页结果。这样,观察回调可以被重复调用,但请求入口只有一个。

const list = document.querySelector('#list');
const sentinel = document.querySelector('#sentinel');
let page = 1;
let loading = false;
let hasMore = true;

async function loadMore() {
  if (loading || !hasMore) return;
  loading = true;
  try {
    const response = await fetch(`/api/articles?page=${page}`);
    const result = await response.json();
    for (const item of result.items) {
      const li = document.createElement('li');
      li.textContent = item.title;
      list.append(li);
    }
    page += 1;
    hasMore = result.hasMore;
  } finally {
    loading = false;
  }
}

const observer = new IntersectionObserver((entries) => {
  for (const entry of entries) {
    if (entry.target !== sentinel || !entry.isIntersecting) continue;
    if (loading || !hasMore) continue;
    observer.unobserve(sentinel);
    loadMore().finally(() => {
      if (hasMore) observer.observe(sentinel);
    });
  }
}, { rootMargin: '240px 0px' });

observer.observe(sentinel);

这段代码里,entry.target !== sentinel 过滤掉无关目标,loading || !hasMore 是并发与末页门禁,observer.unobserve(sentinel) 关闭当前批次的通知,loadMore 完成后才按 hasMore 决定是否重新观察。不要在 finally 里无条件 observe,否则末页的 sentinel 仍可能不断触发空请求。

前端长列表由 loading 和 hasMore 共同保护 loadMore 请求并在完成后恢复 sentinel 观察

快速滚动时要核对三个可见结果

rootMargin 设成 240px 是为了提前加载,但它不会改变并发语义。测试时连续拖动滚动条到底部,观察 Network 面板:同一个 page 在响应返回前只能出现一个请求;列表追加后,下一页请求才出现;接口返回 hasMore: false 后不再有新的请求。

现象应核对的状态处理判断
回调多次进入loading === true直接返回,不新增请求
列表已经到底hasMore === false保持 unobserve
下一页已追加loading === falsehasMore === true重新 observe sentinel

相关问题:把观察回调当成请求生命周期

为什么初次 observe 就可能加载?

因为观察器会给初始交集通知。如果 sentinel 一开始就在视口或 rootMargin 内,回调会立即进入加载分支;这不是异常,应该由首屏是否需要预取来决定。

为什么只写 unobserve 仍会重复请求?

如果 loadMore 失败后无条件重新 observe,失败场景会持续重试。应把重试按钮或退避策略放到错误状态中,成功路径才恢复观察。

为什么 hasMore 不能根据 items.length 猜?

最后一页可能刚好返回满页,空数组也可能是过滤后的合法结果。优先使用接口明确返回的 hasMore 或 nextCursor,避免把分页边界交给猜测。

发布前的最小验收清单

先用慢网速模拟响应延迟,再快速滚动;确认同页没有并发重复请求。接着让接口返回 hasMore: false,确认 loadMore 完成后没有再次 observe。最后在 Network 面板核对请求页码递增、列表 DOM 只追加一次。这样检查的重点不是“回调执行了几次”,而是每个业务页是否只拥有一个未完成请求。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>