MutationObserver 的内存安全取决于引用关系与主动管理：目标节点持强引用阻止观察器回收，需手动 disconnect()；MutationRecord 持有节点引用易致泄漏，应只提取必要字段；组件卸载时须清理监听。
MutationObserver 的监听器回收机制设计得比较克制，关键在于它对目标节点使用弱引用，但目标节点却持有对观察器的强引用。这意味着：只要目标节点还在 DOM 中且可被访问，对应的 MutationObserver 实例就不会被垃圾回收；而一旦目标节点被移除、且不再被其他代码引用，整个观察器连同其内部状态（包括未处理的记录）也会随之释放。
弱引用与强引用的不对称关系
这是理解内存安全的核心。MutationObserver 实例本身不阻止目标节点被回收——它只“看着”，不“拽着”。但反过来，目标节点的 observers 列表里会保存对该观察器的强引用。所以：
- 如果观察的是某个临时容器（比如弹窗内容区），关闭弹窗时把容器从 DOM 移除，观察器通常会自动失效并被回收
- 如果观察的是
document.body或长期存在的节点，而你又没手动调用disconnect()，观察器就会一直驻留内存 - 即使回调函数已执行完毕，只要观察器仍在运行状态（即未 disconnect），它就保持活跃
MutationRecord 可能引发的内存泄漏
每个 MutationRecord 都会持有对相关 DOM 节点的引用（例如 addedNodes、target）。如果你在回调中把整条记录存进全局变量或闭包里，这些节点就无法被回收，哪怕它们早已从页面移除。
- 常见风险场景：把
mutations数组缓存起来做审计日志，或用于后续比对 - 安全做法：只提取必要字段（如节点 tagName、attributeName、变化时间戳），构造轻量对象存储，然后丢弃原始 record
- 特别注意
characterData类型记录——它引用的是文本节点，容易被忽略但同样阻碍回收
主动管理才能保障内存安全
浏览器不会替你决定什么时候该停掉监听。尤其在单页应用中，组件卸载、路由切换时若忘记清理，观察器可能持续监听已不存在的逻辑上下文，造成资源滞留。
- 务必在不需要监听时调用
observer.disconnect()，这是最直接的释放方式 - 如果只是暂停监听，可用
takeRecords()清空队列，再择机恢复，避免堆积 - 在框架生命周期钩子中绑定清理逻辑（如 Vue 的
beforeUnmount、React 的useEffect cleanup） - 避免在回调里重新
observe()同一节点——这会叠加引用，增加回收难度
本质上，MutationObserver 不是“自动托管”的监听器，它的内存安全性取决于开发者是否及时切断引用链。不复杂但容易忽略。
