document.createTreeWalker的核心筛选逻辑是whatToShow位掩码与NodeFilter函数的“且”关系组合：whatToShow预筛节点类型（如NodeFilter.SHOW_ELEMENT），acceptNode再按业务规则返回FILTER_ACCEPT/REJECT/SKIP，二者缺一不可，且acceptNode必须严格返回标准常量。
什么是 document.createTreeWalker 的核心筛选逻辑
它不是靠 CSS 选择器或 XPath 匹配节点，而是通过一个 whatToShow 位掩码 + 一个可选的 NodeFilter 函数共同决定“哪些节点能被遍历到”。whatToShow 控制节点类型（如只看元素、只看文本），NodeFilter 则进一步做业务判断——比如“只保留 class 含 'active' 的 <div>”。两者是“且”关系，缺一不可。
常见错误是只写 NodeFilter 却忽略 whatToShow，结果连 Element 节点都进不来（默认值是 NodeFilter.SHOW_ALL，但某些浏览器旧版本行为不一致，显式指定更稳）：
const walker = document.createTreeWalker(
root,
NodeFilter.SHOW_ELEMENT, // 必须显式声明，否则可能跳过所有元素
{
acceptNode(node) {
return node.classList?.contains('active')
? NodeFilter.FILTER_ACCEPT
: NodeFilter.FILTER_REJECT;
}
}
);
acceptNode 返回值必须严格用 NodeFilter.FILTER_ACCEPT 等常量
返回 true / false 或数字 1 / 0 都无效，会直接导致遍历中断或静默失败。这是最容易踩的坑——控制台无报错，但 walker.nextNode() 突然返回 null。
-
NodeFilter.FILTER_ACCEPT：当前节点被纳入遍历流，nextNode()会返回它 -
NodeFilter.FILTER_REJECT：跳过该节点及其全部子树（彻底剪枝） -
NodeFilter.FILTER_SKIP：跳过该节点，但继续遍历其子节点（适合“过滤容器但保留内容”场景）
例如想收集所有带 data-id 的元素，但不想进入 <script> 内部：
立即学习“前端免费学习笔记（深入）”；
acceptNode(node) {
if (node.tagName === 'SCRIPT') return NodeFilter.FILTER_SKIP;
if (node.hasAttribute('data-id')) return NodeFilter.FILTER_ACCEPT;
return NodeFilter.FILTER_REJECT;
}
遍历时注意节点引用是实时的，DOM 变动会影响后续遍历
TreeWalker 不是快照，它持有一个对 DOM 的实时引用。如果在遍历中修改了已访问节点的父级结构（比如移除某个祖先元素），后续调用 nextNode() 可能抛出异常或返回意外节点。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
安全做法是先收集目标节点引用，再统一处理：
const targets = [];
let node;
while ((node = walker.nextNode()) !== null) {
targets.push(node); // 立即保存引用
}
// 此时再对 targets 做 remove()、setAttribute() 等操作
targets.forEach(el => el.remove());
另一个常见陷阱：在 acceptNode 中修改当前节点（如 node.remove()），会导致遍历器状态错乱，下一次 nextNode() 行为不可预测。
替代方案对比：querySelectorAll 何时更合适
如果只需要静态匹配、不关心遍历顺序或父子关系控制，querySelectorAll 更简洁高效。但 TreeWalker 的不可替代性在于：
- 能按深度优先顺序稳定遍历（
querySelectorAll结果顺序依赖实现，通常文档流，但不保证） - 可在遍历中动态决定是否进入子树（
FILTER_SKIPvsFILTER_REJECT） - 天然支持“找到第 N 个匹配项就停”，避免全量收集浪费内存
例如“找第二个含 aria-expanded="true" 的按钮，且不扫描其子树”——这种混合条件，TreeWalker 比循环 + querySelectorAll + 手动计数更清晰可靠。
真正难的是把业务条件准确拆解成 whatToShow 和 acceptNode 的组合，而不是 API 调用本身。多试两次，观察 walker.currentNode 在每次 nextNode() 后的变化，比查文档更快定位问题。
