MutationObserver性能良好，但监听范围过大、配置不当或未及时清理会拖慢页面、堆积内存；应精准限定目标节点、合理配置childList/attributeFilter、避免同步布局操作、及时调用disconnect()。
MutationObserver 本身性能不错，但用法不当容易拖慢页面、堆积内存。真正影响效果的，是监听范围、配置粒度和生命周期管理。
精准限定观察目标
只监听真正需要响应的节点，避免 document.body 或大容器。比如一个商品列表组件，就只观察它的根元素，而不是整个页面。
- 用 document.getElementById 或 querySelector 明确获取目标节点
- 保持 subtree: false（默认值），除非确实要监听后代节点
- 若只关注子节点增删，开启 childList: true 即可，关闭 attributes 和 characterData
- 需监听属性时，配合 attributeFilter: ['class', 'data-status']，跳过 style、id 等无关变更
减少回调频次与主线程压力
MutationObserver 虽自动合并微任务内变动，但复杂处理仍可能造成卡顿。关键在“不立刻做，而是在合适时机做”。
- 回调中避免同步布局操作（如 getBoundingClientRect()），如需尺寸，包在 requestAnimationFrame 中
- 用 setTimeout 或 requestIdleCallback 延后执行耗时逻辑
- 对 mutations 数组做摘要判断：例如只关心“是否有新节点”，不必遍历每条记录
- 批量 DOM 操作优先使用 DocumentFragment，从源头降低触发次数
及时清理，防止内存泄漏
长期挂载却未断开，是单页应用中最常见的内存隐患之一。尤其在组件卸载、弹窗关闭后极易被忽略。
- 组件销毁前必须调用 observer.disconnect()
- 避免重复创建实例，可复用已有 observer 并重新调用 observe()
- 临时暂停监听时，用 takeRecords() 清空队列，再择机恢复
- 慎用 attributeOldValue 和 characterDataOldValue，仅当真需前后值对比时才开启
不复杂但容易忽略。真正拖慢页面的，往往不是 MutationObserver 本身，而是它监听了什么、何时开始、以及谁来收尾。
