NodeIterator 无法直接遍历 Attr 节点，因其仅遍历 document 树中的活动子节点，而 Attr 节点挂载在 Element 上、不属 childNodes；NodeFilter.SHOW_ATTRIBUTE 被浏览器忽略，须改用 SHOW_ELEMENT + hasAttribute 判断或 attributes 集合操作。
Document.createNodeIterator 本身不直接检索属性节点（Attr），因为它的遍历范围仅限于 元素、文本、注释等 Node 类型，而 Attr 节点在 DOM 标准中**不属于 document 树的活动子节点**——它们挂载在 Element 上，但不在 NodeIterator 的遍历路径中。
为什么不能用 NodeIterator 直接查 attribute 节点
根据 DOM 规范，NodeIterator 遍历的是“活动子树”（live subtree），其起点是某个 Node（如 document 或某个 element），然后按深度优先顺序访问其后代节点。Attr 节点虽然可通过 element.attributes 获取，但它们不是该 element 的 childNode，也不参与 document.childNodes 或 tree-walking 流程。因此：
-
NodeFilter.SHOW_ATTRIBUTE是一个保留常量，但所有主流浏览器都忽略它，传入后无实际效果 - 调用
createNodeIterator(root, NodeFilter.SHOW_ATTRIBUTE)不会返回任何 Attr 节点 - 试图在迭代中检测
node.nodeType === Node.ATTRIBUTE_NODE永远不会命中
替代方案：高效定位带特定属性的元素
如果你的真实目标是“找到所有具有某属性（如 data-track 或 aria-expanded）的元素”，正确做法是用 NodeIterator 遍历元素节点，并在回调中检查其是否拥有目标属性：
- 设置
whatToShow = NodeFilter.SHOW_ELEMENT - 提供自定义
filter函数，在其中用element.hasAttribute('xxx')或'xxx' in element判断 - 这样既保持遍历轻量，又避免全量 querySelectorAll 带来的静态快照开销
const iter = document.createNodeIterator(
document.body,
NodeFilter.SHOW_ELEMENT,
{
acceptNode(node) {
return node.hasAttribute('data-id')
? NodeFilter.FILTER_ACCEPT
: NodeFilter.FILTER_REJECT;
}
}
);
let el;
while (el = iter.nextNode()) {
console.log(el); // 每个都有 data-id 的元素
}
若真需处理 Attr 对象本身，应改用 attributes 集合
当必须操作属性节点（例如监听 attr 变化、读取命名空间前缀、访问 Attr.specified），应直接访问元素的 attributes 属性（返回 NamedNodeMap）：
-
element.attributes.getNamedItem('class')获取指定 Attr 节点 -
element.attributes.forEach(attr => {...})（现代浏览器支持） - 配合
MutationObserver监听attributes: true可响应式捕获变更
性能与适用场景提醒
NodeIterator 适合流式、条件苛刻、且需响应 DOM 实时变化的遍历；但对纯属性检索，多数情况 document.querySelectorAll('[data-xxx]') 更直观高效。只有当你需要：
- 遍历范围受限（如只查某个容器内）
- 判断逻辑复杂（如属性值需正则匹配 + 元素可见性校验）
- 避免创建 NodeList、减少内存分配
才值得封装 NodeIterator 方案。
