TreeWalker 的 FILTER_SKIP 与 FILTER_REJECT 为什么影响不同子树

用 TreeWalker 处理一棵 DOM 树时，FILTER_SKIP 和 FILTER_REJECT 都会让当前节点不出现在遍历结果里，但它们对后代的态度完全不同：前者是“跳过这个节点，继续往下看”，后者是“这个节点下面整棵子树都不要看”。因此，想隐藏一个容器标签却保留内部文本时用 FILTER_SKIP；想排除广告、注释区或敏感分支时才用 FILTER_REJECT。

官方参考：https://developer.mozilla.org/en-US/docs/Web/API/TreeWalker

先把 TreeWalker 看成一棵过滤后的树

TreeWalker 不是把所有节点简单排成一列。它从 root 出发，根据 whatToShow 和过滤函数建立一棵“逻辑可见树”，然后由 nextNode()、firstChild() 或 parentNode() 在这棵树上移动。

这里有一个容易混淆的层次：whatToShow 先决定哪些节点类型会交给过滤器；filter 再决定当前节点是接受、跳过还是拒绝。如果只设置 SHOW_TEXT，元素节点根本不会进入 acceptNode()，过滤器也就没有机会根据元素的 data-skip 属性裁剪分支。

可以先用下面这张表判断返回值：

FILTER_SKIP 为什么还能找到子节点

假设文章中有一个 section 容器，它本身不是我们要收集的节点，但内部的 p 和文本仍然有价值。这时返回 FILTER_SKIP，等于把当前标签从逻辑树中拿掉，同时把它的后代接到继续遍历的路径上。

const walker = document.createTreeWalker(
  document.querySelector("#article"),
  NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT,
  (node) => {
    // 容器标签不计入结果，但不能阻断里面的正文节点
    if (node.nodeType === Node.ELEMENT_NODE) {
      return node.matches("section.content")
        ? NodeFilter.FILTER_SKIP
        : NodeFilter.FILTER_ACCEPT;
    }

    // 只接收有实际内容的文本，排除缩进产生的空白节点
    return node.data.trim()
      ? NodeFilter.FILTER_ACCEPT
      : NodeFilter.FILTER_SKIP;
  },
);

const nodes = [];
let current;
while ((current = walker.nextNode())) {
  // current 可能是元素，也可能是非空文本节点
  nodes.push(current);
}

这个例子里，section.content 自己不会被 nextNode() 返回，但它下面的段落和文本仍有机会通过过滤器。注意，FILTER_SKIP 并不等于“忽略这个节点以后所有内容”，它只是改变当前节点在过滤后树中的位置。

FILTER_REJECT 为什么会剪掉整棵子树

如果页面里有 aside data-skip，你希望里面的标题、链接和文本都不被处理，那么返回 FILTER_REJECT。TreeWalker 会把这个节点和它的后代一起排除，后代不会再逐个进入过滤器。

const article = document.querySelector("#article");
const walker = document.createTreeWalker(
  article,
  NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT,
  (node) => {
    if (node.nodeType === Node.ELEMENT_NODE) {
      // 黑名单容器直接剪枝，后代不会继续参与遍历
      if (node.hasAttribute("data-skip")) {
        return NodeFilter.FILTER_REJECT;
      }

      // 普通元素只作为结构节点，不必成为最终文本结果
      return NodeFilter.FILTER_SKIP;
    }

    // 文本节点保留非空内容，空白只用于排版，不加入结果
    return node.data.trim()
      ? NodeFilter.FILTER_ACCEPT
      : NodeFilter.FILTER_SKIP;
  },
);

const textParts = [];
let node;
while ((node = walker.nextNode())) {
  // 这里的 node 已经只包含通过过滤器的文本节点
  if (node.nodeType === Node.TEXT_NODE) {
    textParts.push(node.data.trim());
  }
}

const result = textParts.join(" ");

这段代码使用 SHOW_ELEMENT | SHOW_TEXT 很关键：只有元素节点进入候选集合，过滤器才能看见 data-skip 并执行剪枝；文本节点则负责提供最终内容。若改成只显示文本节点，aside 会在过滤器之前被跳过，它下面的文本反而可能继续被访问。

实际排查时先分清“节点类型筛选”和“子树剪枝”

TreeWalker 结果为空，不一定是 FILTER_REJECT 写错了。可以按下面顺序排查：

1. 先确认 root 不是空值，且目标节点确实在它的后代范围内。
2. 确认 whatToShow 包含过滤器要检查的节点类型；要按元素属性排除分支，就不能只写 SHOW_TEXT。
3. 确认普通容器返回的是 FILTER_SKIP，而不是误用 FILTER_REJECT。
4. 确认文本过滤使用 trim() 只是排除空白，不要把有意义的文本误判为空。

还要记住 FILTER_REJECT 的差异只在 TreeWalker 的树形遍历语义中成立。对 NodeIterator 来说，FILTER_REJECT 和 FILTER_SKIP 都不会阻止继续检查子节点；如果任务是“裁剪整个子树”，应选择 TreeWalker，或在 NodeIterator 外层自行维护祖先状态。

常见问题

FILTER_SKIP 会不会让当前节点的后代变成直接子节点？

在 TreeWalker 的逻辑视图里可以这样理解：当前节点不显示，但后代仍然可能成为可导航的后续节点。原始 DOM 结构并没有被修改。

为什么我返回 FILTER_REJECT 后，过滤器没有再收到后代节点？

这是预期行为。TreeWalker 会把被拒绝节点的整棵子树剪掉，因此后代不会继续进入过滤器。

只收集文本时，为什么还要 SHOW_ELEMENT？

因为元素节点承担了“是否剪枝”的判断入口。先让元素进入过滤器，再对文本节点返回 ACCEPT，才能同时完成子树排除和正文提取。