IntersectionObserver takeRecords 怎样在断开前取回待处理条目

如果组件即将卸载，或一个 IntersectionObserver 不再需要继续观察，收尾顺序应是：先调用 takeRecords() 取回尚未交给回调的条目，处理这些 IntersectionObserverEntry，最后再调用 disconnect()。takeRecords() 返回的是当前待处理队列，并会把队列清空；它不是重新计算元素可见性的同步查询。

这篇只讨论观察器关闭前的队列收尾，不把 rootMargin 的预加载策略混进来。示例中的图片均为静态结构说明图，不是浏览器截图，也不代表示例已经在本机执行。

官方资料：https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserver/takeRecords

先分清回调已经收到什么

IntersectionObserver 的交叉变化不是通过同步读取立即返回，而是以 IntersectionObserverEntry 列表交给回调。浏览器把发生变化的条目排入观察器自己的待处理列表，回调被调度时会拿到其中一批。

因此，组件清理时存在一个容易忽略的时间窗口：某个元素已经发生了交叉变化，但回调还没有处理这条记录。如果此时直接销毁观察器，业务层可能看不到这次最后状态变化。takeRecords() 的用途就是把此刻仍在队列里的记录一次性取出来。

用同一个处理函数收尾待处理记录

最稳妥的写法是把“处理一批条目”的逻辑独立出来，让正常回调和关闭前排空共用它。这样不会因为清理路径另写一套判断，导致最后一批记录的业务规则不一致。

// 统一处理回调和清理阶段拿到的交叉记录
function handleEntries(entries) {
  for (const entry of entries) {
    // isIntersecting 表示当前记录是否处于相交状态
    const target = entry.target;
    target.classList.toggle("is-visible", entry.isIntersecting);
  }
}

const observer = new IntersectionObserver((entries) => {
  // 正常异步通知直接复用同一处理函数
  handleEntries(entries);
});

for (const element of document.querySelectorAll("[data-lazy]")) {
  // 只观察需要延迟处理的目标元素
  observer.observe(element);
}

function stopObserving() {
  // 先取出尚未交给回调的记录，避免清理时漏掉最后状态
  const pendingEntries = observer.takeRecords();
  handleEntries(pendingEntries);

  // 取回记录后再停止所有观察
  observer.disconnect();
}

这里的关键不是把 takeRecords() 当成“立即检测所有元素”，而是消费观察器已经积累的记录。返回值是数组；如果当前没有待处理条目，直接交给 handleEntries 也不会产生额外动作。

为什么必须先 takeRecords 再 disconnect

disconnect() 会停止观察所有目标元素，并清除观察器继续接收变化的关系。把它放在前面，就失去了在清理阶段继续从该观察器取回待处理记录的可靠入口。

推荐把清理顺序固定成下面这条短链路：

1. 调用 takeRecords() 获取尚未分发的条目。
2. 用与普通回调相同的函数处理返回数组。
3. 调用 disconnect() 结束观察。
4. 释放组件自身持有的引用或事件监听器。

如果清理逻辑可能被多个生命周期入口调用，可以加一个状态位避免重复处理自身资源，但不要用重复调用 takeRecords() 来推断元素当前可见性。第一次调用已经清空当时的待处理队列，第二次通常只会得到空数组。

把清理逻辑放进组件卸载路径

在组件系统里，观察器常常与某个列表或图片集合绑定。清理函数要同时负责排空队列和断开观察，不能只在“创建新观察器”时调用 disconnect()，否则卸载时可能遗漏最后一批记录。

function createVisibilityController(elements) {
  let stopped = false;

  const observer = new IntersectionObserver((entries) => {
    // 已进入清理阶段时，不再把迟到回调写回已卸载的视图
    if (!stopped) handleEntries(entries);
  });

  for (const element of elements) {
    // 观察器只接收当前控制器负责的目标
    observer.observe(element);
  }

  return () => {
    if (stopped) return;
    stopped = true;

    // 清理前仍要处理已经排队但尚未交付的记录
    const pendingEntries = observer.takeRecords();
    handleEntries(pendingEntries);

    // 完成最后一批记录后解除观察关系
    observer.disconnect();
  };
}

这里的 stopped 只保护后续异步回调不要继续触碰已卸载视图；它不应阻止清理函数在设置状态后读取一次已经存在的待处理队列。若处理记录本身会更新组件状态，还应根据组件框架的卸载语义决定是否将最后一批记录写入外部缓存。

不要把 takeRecords 当成同步可见性查询

takeRecords() 只返回“自上次检查以来已经产生、但尚未交给回调”的记录。它不保证数组里有所有当前可见目标，也不会替代 getBoundingClientRect() 或布局测量。若业务需求是立即知道某个元素此刻的几何位置，那是另一类同步测量问题。

还要注意三点边界：

• 调用 takeRecords() 会清空待处理列表，被取出的记录不会再次因为同一队列自动触发原回调。
• 如果正常回调已经收到并处理了记录，随后调用 takeRecords() 不会返回同一批数据。
• 如果只需要停止观察而不关心尚未分发的状态，直接 disconnect() 可以更简单；是否排空取决于业务是否需要最后一次状态。

按生命周期职责做发布前检查

最后可以把这条规则写进组件的资源清单：凡是创建了 IntersectionObserver，就同时登记一个清理函数；凡是清理函数需要保留最后状态，就先排空队列，再断开观察。这样既保留异步观察的低侵入性，也让卸载时的边界行为变得明确。

takeRecords 会主动触发 IntersectionObserver 回调吗？

不会。它直接返回待处理条目并清空队列；取出的条目应由调用方决定是否复用原来的处理函数。

disconnect 之后还能拿到刚才的记录吗？

不要依赖这种顺序。需要保留清理阶段记录时，应先调用 takeRecords，再调用 disconnect。

takeRecords 能替代 rootMargin 吗？

不能。rootMargin 改变交叉判断使用的边界，takeRecords 只负责读取已经产生但尚未交付的记录，二者解决的是不同问题。