treewalker 比递归遍历更适合编辑器场景，因其天然支持文档顺序游标移动、可精确过滤节点类型与子树、支持中断回溯、内存恒定且不生成中间数组，能稳定捕获可编辑内容并跳过无关节点。
直接用 document.createTreeWalker() 就能做深度优先搜索，但必须配对使用 whatToShow 位掩码和正确的 acceptNode 返回值，否则会漏节点或卡死。
为什么 TreeWalker 比递归遍历更适合编辑器场景
编辑器常需精确捕获「可编辑内容节点」（比如非空文本、含 contenteditable 的元素、带语义的 inline 元素），同时跳过 script/style/comment/不可见空白等。手动递归容易忽略节点类型边界、误入 shadow DOM、难以中断或回溯；而 TreeWalker 天然支持文档顺序游标移动，且 nextNode() / previousNode() 能稳定返回下一个「被接受」的节点，不依赖子树结构是否完整。
- 它只遍历 DOM 树中实际存在的节点，不生成新对象，内存开销比
querySelectorAll+ 数组小得多 - 遍历中途可随时用
walker.currentNode获取当前上下文，方便做光标定位、选区映射 - 配合
FILTER_SKIP和FILTER_REJECT能实现「跳过某元素但检查其子节点」或「整棵子树丢弃」两种策略，这对处理嵌套的富文本容器（如<span class="math"></span>）很关键
创建时必须设对的三个参数：root、whatToShow、filter
编辑器里通常以 document.body 或某个 contenteditable 容器为根，但要注意：如果容器是 div[contenteditable="true"]，就别用 document 作根，否则会遍历到 head、script 等无关区域。
-
whatToShow至少要包含NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT，否则文本内容拿不到 - 若需处理注释（比如编辑器的调试标记），加上
NodeFilter.SHOW_COMMENT -
filter不能传函数——必须是带acceptNode(node)方法的对象，且返回值只能是NodeFilter.FILTER_ACCEPT/NodeFilter.FILTER_REJECT/NodeFilter.FILTER_SKIP三者之一；返回true或1会导致遍历提前终止
示例（只接受非空文本和有 data-leaf 属性的元素）：
const walker = document.createTreeWalker(
editorRoot,
NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT,
{
acceptNode(node) {
if (node.nodeType === Node.TEXT_NODE && node.textContent.trim()) {
return NodeFilter.FILTER_ACCEPT;
}
if (node.nodeType === Node.ELEMENT_NODE && node.hasAttribute('data-leaf')) {
return NodeFilter.FILTER_ACCEPT;
}
// 跳过空元素、script、style、comment（即使 whatToShow 包含了它们）
return NodeFilter.FILTER_REJECT;
}
}
);
nextNode() 和 firstChild() 在编辑器导航中的实际差异
编辑器里经常需要「从光标位置向下找下一个可编辑节点」或「进入某个块级元素内部找第一个文本入口」，这时不能混淆两个方法的行为：
-
walker.nextNode()是全局文档顺序推进，不管当前在哪层，都找下一个符合条件的节点（深度优先，从左到右） -
walker.firstChild()只尝试进入walker.currentNode的第一个子节点，且仅当该子节点本身满足whatToShow和filter条件时才成功；失败则返回null，walker.currentNode不变 - 想重头开始遍历？不能只调
walker.firstNode()（不存在这个方法），得先设walker.currentNode = editorRoot，再调walker.firstChild()或walker.nextNode()
常见错误：在循环里反复调 nextNode() 却没判断返回值是否为 null，导致无限循环或报错。
容易被忽略的兼容性与性能点
TreeWalker 在 IE8–完全不支持，但现代编辑器基本已放弃这些版本；真正容易翻车的是以下三点：
- 某些编辑器框架（如 Slate）会动态 patch
childNodes或劫持textContent，导致TreeWalker看到的节点状态和真实 DOM 不一致——建议在操作前用editorRoot.cloneNode(true)做快照遍历，或改用NodeIterator（行为更保守） -
whatToShow中混用NodeFilter.SHOW_ELEMENT和NodeFilter.SHOW_TEXT时，文本节点可能出现在两个相邻元素之间，但编辑器光标逻辑往往假设「文本必属某个父元素」，需额外校验node.parentNode - 大量节点下连续调
nextNode()性能尚可，但若在每次调用中做复杂计算（比如正则匹配整个textContent），会明显卡顿；应把过滤逻辑尽量前置，或用walker.currentNode.compareDocumentPosition()做快速范围判断
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
