JavaScript NodeIterator.detach 为什么不应当作释放 DOM 的方案

NodeIterator.detach() 在现行 DOM 标准中不执行任何操作，方法保留用于兼容历史代码。它不会清空迭代器的 root，不会删除 DOM，也不是触发垃圾回收的开关。要解决页面卸载后节点仍被持有的问题，应结束应用自己的任务并解除不再需要的强引用。

文档入口：https://developer.mozilla.org/en-US/docs/Web/API/NodeIterator/detach。下面围绕节点遍历任务的生产生命周期展开，示例用于说明引用管理，没有在本文环境运行或测量内存变化。

先确认detach的现行语义

名字容易让人想到“断开”，旧代码也可能在 finally 中调用它。但当前规范明确将该方法定义为空操作。不要据此假设迭代器被关闭，或接下来的 nextNode() 必然失败；更不能把调用完成当作资源已经释放的证明。

// 反例：detach并不会清理这个长期持有的迭代器
const jobs = new Map();
function rememberScan(id, root) {
  const iterator = document.createNodeIterator(root, NodeFilter.SHOW_TEXT);
  jobs.set(id, iterator); // Map仍然持有iterator
  iterator.detach(); // 现行标准中的空操作，不是释放动作
}

上例真正值得关注的是 jobs 到 iterator，再到 root 及其子树的引用关系。referenceNode 也表示遍历当前位置；filter 若使用捕获外部对象的回调，还可能带来额外持有关系。调用 detach 不会把这些应用层关系自动撤销。

让一次遍历只返回需要的数据

同步扫描若只需要文本，就把迭代器限制在函数内部，并返回字符串，而不是返回节点数组或把迭代器登记到全局列表。

// 由调用方提供真实根节点，只收集非空文本值
function collectText(root) {
  if (!(root instanceof Node)) {
    throw new TypeError("需要当前窗口中的DOM节点");
  }
  const iterator = document.createNodeIterator(root, NodeFilter.SHOW_TEXT);
  const values = [];
  let node;
  while ((node = iterator.nextNode()) !== null) {
    const value = node.data.trim();
    if (value) values.push(value); // 返回值不持有DOM节点
  }
  return values;
}

函数返回后，局部 iterator 没有被结果数组带出去。这不保证 root 被回收：调用方或文档本身仍可能持有它。这个设计只缩短扫描代码引入的引用周期。若树很大、结果很多，字符串数组本身也会占用内存，需要另行决定是否采用分批处理。

长期任务在销毁时断开自己的引用

需要分批遍历时，迭代器必须跨调用存在。可以用明确的会话对象承载它，在 finish 或 dispose 中置空会话字段；销毁动作只影响会话拥有的引用，不去删除外部传进来的 DOM。

// 会话拥有迭代器，不拥有root对应界面的删除权限
class TextScanSession {
  constructor(root) {
    this.iterator = document.createNodeIterator(root, NodeFilter.SHOW_TEXT);
  }
  readBatch(limit = 100) {
    if (!Number.isInteger(limit) || limit 

刚好读满一批时，done 仍可能为 false，下一次读取才发现已经耗尽；调用方应遵守返回协议或在取消时主动 dispose。若外层还有定时器、事件订阅或异步调度，也要由其拥有者取消，避免销毁后继续访问旧会话。置空一个字段不会自动取消排队的回调。

把移除节点与内存回收分开

从文档移除元素，仅表示它不再位于该文档树中。如果仍有可达对象持有节点、迭代器或闭包，相关对象仍可能存活。反过来，不可达的相互引用并不必然泄漏，现代垃圾回收关注可达性，不要求手动拆掉所有环。

因此，发现节点脱离文档后仍存活，应先定位实际保留链：例如任务 Map 是否忘记 delete，结果缓存是否保存了 Node，订阅是否仍保留捕获界面的回调。不要把所有事件监听器都一概视作泄漏；关键在于是否存在从仍存活对象出发的保留路径。

如果应用确实负责移除界面，再由界面拥有者执行移除；不要为了释放扫描器擅自 root.remove()。即使变量赋为 null，垃圾回收时机也由运行时决定，不能用“下一行内存立刻下降”作为契约。

迁移旧代码并处理常见疑问

迁移时先区分普通浏览器原生 NodeIterator 和项目自定义封装。对于自定义对象，名称相同并不意味着方法也是空操作；只能按其真实实现决定是否删除调用。新封装中的 dispose 可以有明确业务语义，但不要宣称它直接控制浏览器回收器。

把iterator设为null就一定释放DOM吗？

不会。它只断开这一条变量引用；文档、缓存、其他会话仍可持有节点。

还需要保留detach来兼容现代浏览器吗？

现行原生接口把它保留为兼容空操作，新代码不应依赖它释放资源。涉及特殊嵌入式环境或自定义包装时，应单独确定支持范围。

WeakMap能替代所有清理逻辑吗？

不能。弱引用数据结构不是任务取消机制，也不能让仍被其他强引用持有的对象失去可达性。先把拥有者和结束动作定义清楚。

参考：MDN detach方法说明、DOM标准、JavaScript内存管理。