DOM MutationObserver实例成本对比：元素移除检测方案选型咨询

场景与关键约束 #

• 需检测带有class="my-class"的DOM元素的移除操作，已知元素插入时机，但移除逻辑由外部不可控代码处理
• 目标元素可出现在DOM任意位置，数量无上限

候选方案 #

方案1：全局单实例深度监听 #

• 创建单个MutationObserver实例，监听document.body的childList变化并开启subtree: true配置
• 回调触发时，在被移除的节点子树中通过querySelectorAll('.my-class')筛选目标元素

方案2：元素级多实例浅度监听 #

• 每当新的目标元素插入DOM时，为其创建独立的MutationObserver实例，仅监听该元素本身（无需subtree配置）
• 元素被移除时触发回调，随后调用disconnect()销毁该观察者实例

选型建议与核心疑问解答 #

单个MutationObserver实例的成本 #

单个MutationObserver实例的运行与内存成本极低。浏览器对该API做了大量底层优化：它会批量合并DOM变化事件，而非每次变动都立即触发回调；单实例仅需维护一套监听配置与回调逻辑，内存占用远低于大量零散的实例。

深度监听与浅度监听的成本差异 #

• 深度监听（subtree: true）：会覆盖目标节点的所有子树，触发回调的场景更多，但浏览器会自动合并同类变动，实际性能开销并不夸张。需要注意的是，回调中频繁执行querySelectorAll会带来额外开销，但类选择器是浏览器高度优化的查询方式，效率足够应对绝大多数场景。
• 浅度监听：仅监听单个元素的移除，回调逻辑极简，但当目标元素数量极多时，大量MutationObserver实例会累积内存占用，每个实例都需要绑定回调、维护监听状态，长期来看内存开销会显著高于单实例方案。

最终选型结论 #

优先选择方案1，核心原因：

• 内存更可控：单实例避免了大量观察者实例的内存累积，适配目标元素数量无上限的场景
• 维护成本低：仅需一套回调逻辑，无需处理实例的创建、销毁生命周期
• 性能更稳定：浏览器的批量事件处理+高效的类选择器查询，整体性能优于多实例方案

若想进一步优化querySelectorAll的开销，可以在回调中先判断节点本身是否为目标元素，再递归检查子节点，减少不必要的选择器调用：

function handleRemovedNodes(removedNodes) {
  const targetElements = [];
  for (const node of removedNodes) {
    if (node.nodeType !== Node.ELEMENT_NODE) continue;
    // 先检查当前节点是否是目标元素
    if (node.classList.contains('my-class')) {
      targetElements.push(node);
    }
    // 再查询子节点中的目标元素
    targetElements.push(...node.querySelectorAll('.my-class'));
  }
  // 在这里处理目标元素被移除后的逻辑
}

内容的提问来源于stack exchange，提问作者Itay Maman