组件卸载时如何手动断开 observer 连接以防止浏览器内存积压

useInView 的 observer 必须在 unmount 时显式销毁，否则导致内存泄漏；Vue 指令中需在 unmounted 调用 disconnect()；原生 IntersectionObserver 必须调用 disconnect() 才能释放资源。

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 <div ref={ref}>内容</div>;};

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 的启停，而不是销毁后重建。