组件卸载时若未正确断开 IntersectionObserver 连接，将引发严重的内存泄漏——残留的 observer 持续引用 DOM 节点，导致 detached nodes 积压、性能下降甚至页面卡顿；无论 React 的 useInView、Vue 3 自定义指令、原生 IntersectionObserver 还是 Lozad.js，都必须在组件销毁（或失活）时显式调用 disconnect() 或 destroy()，且清理逻辑务必置于 useEffect 清理函数、unmounted 钩子等确切的卸载时机中，任何依赖垃圾回收、忽略 ref 变更、遗漏 cleanup 或误将实例置 null 的做法，都会让内存泄漏悄然发生。

React 中 useInView 的 observer 必须在 unmount 时销毁

React Intersection Observer 的 useInView Hook 默认不自动清理，尤其在频繁挂载/卸载的列表项或模态框中，未清理的 IntersectionObserver 实例会持续持有 DOM 引用，导致内存无法释放。浏览器 DevTools 的 Memory 面板中常表现为 detached DOM nodes 持续增长。

关键点是：Hook 返回的 unobserve 函数必须被显式调用，不能依赖 GC 自动回收。

• unobserve 只对当前绑定的 ref 元素生效，若 ref 改变（如列表重渲染），旧 observer 不会自动失效
• 不要在 useEffect 里只依赖空依赖数组 —— 卸载逻辑必须写在 cleanup 函数中
• 若使用自定义 Hook 封装 useInView，需确保其返回的 cleanup 能穿透到组件层

const MyComponent = () => {
  const [ref, inView] = useInView({ threshold: 0.1 });
  
  useEffect(() => {
    if (inView) {
      console.log('可见了');
    }
    // ✅ 正确：unmount 时调用 unobserve（即使没用到 inView）
    return () => {
      if (ref.current) {
        // 注意：useInView 不直接暴露 unobserve，需用 ref 解绑
        // 实际应使用其返回的 unobserve 函数（见下节）
      }
    };
  }, [inView, ref]);

  return 内容;
};

Vue 3 自定义指令中 observer 的销毁时机必须是 unmounted

在 Vue 3 的 v-intersect 类指令中，若内部新建了 IntersectionObserver，其生命周期必须严格对齐组件。unmounted 钩子是唯一安全的清理入口 —— beforeUnmount 可能因异步操作延迟而错过 DOM 移除时机，updated 或 deactivated 则完全不可靠。

• observer 实例必须作为指令的 binding.instance 或 el.__observer 挂载到元素上，否则卸载时无法访问
• 避免在 mounted 中重复创建 observer：检查 el.__observer 是否已存在，防止叠加监听
• 若指令支持动态参数（如 v-intersect:[threshold]），更新时应先 unobserve 再重建，而非直接覆盖

const vIntersect = {
  mounted(el, binding) {
    const options = { threshold: binding.value || 0 };
    const observer = new IntersectionObserver((entries) => {
      entries.forEach(entry => {
        if (entry.isIntersecting) {
          el.dispatchEvent(new CustomEvent('intersect', { detail: entry }));
        }
      });
    }, options);
    observer.observe(el);
    el.__observer = observer; // 保存引用供卸载用
  },
  unmounted(el) {
    if (el.__observer) {
      el.__observer.disconnect(); // ✅ 必须调用 disconnect()
      el.__observer = null;
    }
  }
};

原生 IntersectionObserver 实例的 disconnect() 不能省略

很多人误以为把 IntersectionObserver 实例设为 null 就算清理了，但只要实例还持有 callback 和 root 引用，且未调用 disconnect()，浏览器就认为它仍在工作。DevTools Performance 面板中能看到持续的 intersection-observer 任务堆积。

• disconnect() 是硬性要求：它清空内部观察队列、断开与 DOM 的关联，是唯一能释放资源的操作
• unobserve(target) 只移除单个目标，适合局部更新；整页卸载必须用 disconnect()
• 若 observer 用于监听多个动态插入的元素（如评论流），建议每次 unobserve 后检查 takeRecords().length，确认无残留回调待处理

容易忽略的一点：如果 observer 的 root 是某个滚动容器（非视口），而该容器本身也被卸载，必须先 disconnect() observer，再移除 root —— 否则 observer 会因 root 失效而报错并卡住。

Lozad.js 的 destroy() 方法不是可选，而是必调项

Lozad.js 基于 IntersectionObserver，但它封装了自动重连逻辑（enableAutoReload: true 默认开启），这会导致额外的 MutationObserver 实例。一旦组件卸载而未调用 destroy()，这两个 observer 都会持续监听，内存泄漏风险翻倍。

• destroy() 会同时调用底层 IntersectionObserver.disconnect() 和 MutationObserver.disconnect()
• 若使用 lozad('.lazy') 批量初始化，在单个组件卸载时不能只销毁部分 —— 应按实例粒度管理，每个 observer 对应一个组件作用域
• 在 React 中，推荐用 useRef 保存 observer 实例，并在 useEffect cleanup 中调用 observer.destroy()

最隐蔽的问题：当页面用 keep-alive 缓存组件时，unmounted 不会触发，此时不能依赖常规卸载流程 —— 必须监听 activated/deactivated 钩子，手动控制 observer 的启停，而不是销毁后重建。

今天关于《组件卸载时如何断开observer连接》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！