组件卸载时手动断开observer连接防内存积压

你是否意识到，一个简单的IntersectionObserver若未妥善处理，会在页面中引发怎样的内存灾难？在实践中，这个问题屡见不鲜——组件卸载后，浏览器中的“幽灵DOM”不断累积，页面逐渐变得卡顿，而根源往往就是那个未被及时断开连接的Observer。

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

React 的 useInView Hook 存在一个容易忽视的设计缺陷——它默认不会自动清理 observer 实例。特别是在频繁挂载与卸载的列表项或模态框中，那些未被清理的 IntersectionObserver 实例会牢牢持有 DOM 引用，无法释放。打开浏览器 DevTools 的 Memory 面板，你会看到 detached DOM nodes 像野草一样疯狂增长。

关键问题在于：Hook 返回的 unobserve 函数必须被显式调用，仅依赖垃圾回收机制自动回收并不靠谱。

• 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 再重建，而不是直接覆盖，否则旧的 observer 将成为无人管理的孤儿

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 的启动与停止。注意是启停，而非销毁再重建，否则组件被重新激活时还需重新创建实例，白白浪费性能。