彻底搞懂NodeList：类数组对象的遍历、兼容性与工程实践

说到 NodeList，很多前端同学第一反应是“不就是 querySelectorAll 返回的那个东西嘛”，然后转头就把它当数组用，结果 map 报错、forEach 在某些环境里失踪、length 倒是挺正常——这种“似数组又不是数组”的暧昧状态，几乎每个写过原生 DOM 操作的人都被它坑过。我自己早期写脚本时，就因为在 IE11 里对 NodeList 用了 forEach，线上报错排查了一个多小时，最后才发现是环境兼容问题。所以这篇我把 NodeList 的来龙去脉、遍历方式、静态与动态的区别、以及它在各种 API 场景下的表现，一次讲透，把那些文档里不会写、但实际操作中一定会遇到的细节全抖出来。

1. NodeList 到底是什么玩意儿

1.1 它不是数组，但它长得太像数组了

NodeList 是浏览器提供的一种“类数组对象”，专门用来表示一组 DOM 节点的集合。你可以通过 document.querySelectorAll、document.getElementsByName、以及各种 childNodes 属性拿到它。拿到的瞬间你会觉得它跟数组没啥两样，有 length，能用 [0] 按下标取元素，甚至打印出来在控制台里也能展开看到一个一个的节点。

但你要是真把它当数组用，麻烦就来了。数组的那些方法，push、pop、map、filter、reduce，它默认一个都没有。它身上只有 length 和几个跟遍历相关的接口，比如 forEach、item()、entries()、keys()、values()。这就是所谓“类数组”的核心特征：能读长度、能读下标，但没继承 Array.prototype 上的方法。

这里要稍微理解一下背后的设计逻辑。DOM 操作在浏览器里是高频场景，尤其是早期规范设计时，NodeList 作为一个“快照集合”被设计成轻量的、只读的列表，并不是为了替代数组去承载复杂的数据处理逻辑。它更像是一个“只负责告诉你有哪些节点”的清单，而不是一个“可以随意增删改查”的容器。所以拿数组那套标准去要求它，本身就有点拧巴。

我记得有一次面试别人，问“NodeList 是数组吗”，候选人斩钉截铁说“是”，还给我现场演示 nodeList.includes(node) 能用……在最新版 Chrome 里确实没问题，因为后来的 DOM 规范给 NodeList 补了不少数组风格方法。但这不代表它就是数组，真要判断类型，Array.isArray(nodeList) 返回的是 false。这个细节能在关键时候帮你省下大量调试时间，绝对值得多花一分钟记住。

1.2 有哪些 API 会返回 NodeList

梳理一下日常开发里最常见的 NodeList 来源，用途不同，行为也不同。

• document.querySelectorAll()：最常用，返回静态 NodeList，匹配 CSS 选择器。
• element.childNodes：返回动态 NodeList，包含所有子节点，包括文本节点和注释节点。
• document.getElementsByName()：返回动态 NodeList，按 name 属性匹配。
• Node.childNodes 的各个索引位置访问，也是 NodeList 的一部分。
• document.createTreeWalker() 配合 TreeWalker 遍历时，某些返回值也涉及 NodeList 语义（虽然不直接用 NodeList 对象）。

其中 childNodes 特别容易让人意外，因为它不止返回元素节点，文字、注释、换行符也算。写 ul 里塞了几个 <li>，中间有换行和空格，那 ul.childNodes.length 可能比 ul.children.length 大不少。两个东西区别很明显：children 只收元素节点，childNodes 是“只要是节点就算数”，文字也算。

1.3 静态 NodeList 和动态 NodeList 的区别

这是个高频考点，也是实际开发中最容易导致 bug 的隐形地雷。

静态 NodeList，典型代表是 querySelectorAll 返回的结果。它在调用那一刻就锁定了当时匹配到的节点集合。之后哪怕你在 DOM 里删掉了某个节点、或者新增了一个符合选择器的节点，这个 NodeList 里的内容都不会变，它就是一张“旧照片”。

动态 NodeList，典型代表是 childNodes 和 getElementsByName 返回的结果。它像一个“实时监控”，DOM 发生变化后，你会立刻在这个集合里看到新增或消失的节点，不需要重新查询。

两者怎么选？如果你的逻辑是“查一次，之后所有操作都围绕这一批节点进行，不允许外部干扰”，那静态的更安全。如果你希望保持对 DOM 变化的实时感知，比如做节点增删的观察器、动态表单校验之类，动态的更合适。但要注意，动态 NodeList 如果被长时间持有，会形成对 DOM 的强引用，某些情况下会阻碍垃圾回收，影响性能。

2. 遍历 NodeList 的正确姿势与性能对比

2.1 最直接的 for 循环

既然 NodeList 有 length 和下访问访问，那最朴素的遍历方式自然是 for 循环。比如：

javascript复制const items = document.querySelectorAll('.item');
for (let i = 0; i < items.length; i++) {
  console.log(items[i].textContent);
}

这段代码在任何浏览器里都能跑，没有任何兼容性问题，性能也最好。因为 for 循环不需要额外的上下文切换或迭代器封装，纯粹就是按索引访问。如果你要处理非常大的 NodeList（比如几千个节点），for 循环往往是性能最优解。

我在真实项目中就遇到过一个问题：用 forEach 遍历一万多个表格单元格节点时，页面肉眼可见地卡顿，尤其在低端安卓机上。换成 for 循环后，体感流畅了不少。虽然单次遍历差距可能只有十几毫秒，但在高频调用、加上后续 DOM 操作的情况下，积少成多就很可观。

2.2 forEach 的兼容性陷阱

规范里 NodeList 的 forEach 方法是在 DOM 标准较新版本中才定义的。现代浏览器里可以直接用：

javascript复制document.querySelectorAll('div').forEach(item => {
  item.classList.add('processed');
});

但如果你要兼容 IE 或者一些老旧内核的 WebView，这段代码在运行时就会报 nodeList.forEach is not a function。前面说的那个线上事故就是这么来的——平时开发用的是 Chrome，测试也没覆盖到老旧内核，结果用户侧一打开就白屏。

兼容写法也不复杂，先判断一下有没有 forEach，没有就退回 Array.prototype.forEach.call：

javascript复制const list = document.querySelectorAll('.item');
if (list.forEach) {
  list.forEach(item => { /* ... */ });
} else {
  Array.prototype.forEach.call(list, item => { /* ... */ });
}

或者干脆用 Array.prototype.forEach.call(nodeList, callback) 一劳永逸，因为只要浏览器支持 NodeList，就一定支持 Array.prototype.forEach，这个方法在那里跑不会被拦截。

2.3 for...of 其实是最省心的

如果项目不用兼容老掉牙的浏览器，那我强烈推荐用 for...of。NodeList 是实现了可迭代协议的，也就是说它身上有 Symbol.iterator 方法，所以可以直接放进 for...of 里遍历：

javascript复制const items = document.querySelectorAll('.item');
for (const item of items) {
  console.log(item);
}

这招比 forEach 好在哪里？好处有三个：

• 不需要回调函数，可以直接用 break 和 continue 控制流程，forEach 做不到中途跳出。
• 语义清晰，可读性强，一看就知道在遍历集合。
• 写法贴近数组遍历习惯，心智负担小。

实际开发中，如果只是“拿到一批节点，处理一下加个样式或者绑定个事件”，我一般直接用 for...of。它既不用像 for 那样手动维护索引，也不用担心回调函数的 this 指向问题。

2.4 转成真数组再处理

除了直接遍历，另一个常见操作是先把 NodeList 转成真正的数组，然后就能用 map、filter、reduce 那一整套了。转换方式有几种：

javascript复制const list = document.querySelectorAll('.item');

// 方式一：Array.from
const arr1 = Array.from(list);

// 方式二：展开运算符
const arr2 = [...list];

// 方式三：Array.prototype.slice
const arr3 = Array.prototype.slice.call(list);

// 方式四：Array.prototype.concat
const arr4 = [].concat(list);

推荐优先用 Array.from，因为它语义最明确，而且还能做映射转换：

javascript复制const texts = Array.from(document.querySelectorAll('.item'), el => el.textContent);

一个方法同时完成“转换”和“映射”，代码简洁又高效。展开运算符写法短，但如果有兼容老浏览器的需求就别用了，它是 ES6 语法，要经过转译才能跑，而且转译后有时会引入额外的 polyfill。Array.prototype.slice.call 是比较老的兼容方案，性能也不错，就是对新手不友好，看不懂为什么数组 slice 能拿来处理 NodeList，其实原理也很简单：slice 不关心 this 是不是数组，只要它有 length 属性和索引值就可以工作，这就是“鸭子类型”。

3. 实操环节：从取节点到完整处理的套路积累

3.1 把 NodeList 当数组用的典型场景

这里直接上实战代码。比如批量给一组按钮绑定点击事件：

javascript复制const buttons = document.querySelectorAll('.action-btn');
for (const btn of buttons) {
  btn.addEventListener('click', function () {
    this.classList.toggle('active');
  });
}

再比如，过滤出包含特定文字的元素：

javascript复制const allItems = document.querySelectorAll('.list-item');
const filtered = Array.from(allItems).filter(item => {
  return item.textContent.includes('重要');
});

还有最常见的“给所有 input 设置值”：

javascript复制const inputs = document.querySelectorAll('.form-input');
Array.from(inputs).forEach((input, index) => {
  input.value = `默认值${index + 1}`;
});

这些代码看起来平平无奇，但每一个写法背后都有讲究。比如用 this.classList 而不是在箭头函数里访问 event.target，因为 this 在普通函数里指向当前元素，性能上更直接，少了一层事件对象的属性解析。

3.2 动态 NodeList 造成的遍历坑

动态 NodeList 是个容易忽略的坑。举个典型例子，你想把某个容器里的子节点删除干净：

javascript复制const container = document.getElementById('box');
const children = container.childNodes; // 动态 NodeList

for (let i = 0; i < children.length; i++) {
  container.removeChild(children[i]);
}

看起来天经地义，但执行结果会非常诡异：你会发现删了一部分节点后循环结束，容器里还剩下一半子节点。原因很简单——每删除一个子节点，children.length 就减一，同时 children[i] 的指向也在不断变化。循环开始时 i 从 0 走，删除第 0 个后，原来的第 1 个变成了第 0 个，可索引 i 已经走到了 1，于是跳过了原来的第 1 个（也就是现在的第 0 个）……漏删就是这么来的。

正确做法是倒序遍历：

javascript复制for (let i = children.length - 1; i >= 0; i--) {
  container.removeChild(children[i]);
}

或者干脆用静态快照：

javascript复制const children = Array.from(container.childNodes); // 拍快照
for (const child of children) {
  container.removeChild(child);
}

这个坑在操作 childNodes 时太常见了。哪怕是写了几年前端的人，偶尔也会犯类似的惯性错误——因为大家熟悉的数组通常都是静态的，不会自己变长变短。

3.3 遍历过程中对 DOM 结构改动引发的二次坑

还有一个和动态 NodeList 相关的坑：遍历过程中你改了 DOM，导致后续节点识别错位。比如你想在所有 .item 里插入一个分隔节点：

javascript复制const items = document.querySelectorAll('.item'); // 静态 NodeList
items.forEach((item, index) => {
  const separator = document.createElement('div');
  separator.className = 'separator';
  item.after(separator);
});

这段代码本身没问题，因为 querySelectorAll 是静态的，items 不会因为新插入节点而改变内容。但如果你在插入过程中又用 querySelectorAll 重新查询了 .item，那问题就来了——新插入的节点如果也匹配 .item 选择器，就会把你刚插入的节点也当作目标，导致无限循环、重复插入等问题。

所以在这种“边遍历边修改 DOM”的场景里，一个铁律是：优先使用静态 NodeList，并且在整个遍历过程中不要再重复查询同一个选择器。如果确实需要同时获取“当前所有新生成的节点”，那就要额外加上“只处理原始集合中的节点”逻辑，比如记录一个标志属性，或者提前把节点的引用存下来。

另一个更隐蔽的情况是，在 forEach 回调里做 DOM 操作，而这个操作影响了兄弟节点的结构。比如给每个 .item 都插入一个兄弟节点，导致后续 .item 下标顺序发生变化。如果这里用的是动态 NodeList，遍历过程就会踩到前面说的“索引错位”雷区。解决思路和上面一样：要么用静态快照，要么倒序遍历，要么把操作拆成两个阶段——先收集所有新元素的引用，再统一插入 DOM。

3.4 NodeList.forEach 与 Array.forEach 的差异

很多人以为 NodeList 补了 forEach 就和数组的 forEach 完全一致，其实还是有细微差别的。数组的 forEach 有三个参数：当前元素、当前索引、数组本身。NodeList 的 forEach 也是三个参数：当前节点、当前索引、NodeList 本身。

看起来参数一模一样，但有一个区别：Array.prototype.forEach 在遍历开始时会把数组的长度缓存下来，遍历过程中如果数组内容发生变化（增删元素），循环次数不会变，但访问到的元素可能因为索引移位而变化。NodeList 的 forEach（如果是静态 NodeList）就没这个问题，因为集合内容不变。

另一个差异是 thisArg 参数。两者都支持传入 thisArg 作为回调里的 this 值。这在实际开发中可以用来复用某个对象的方法：

javascript复制const handler = {
  prefix: 'data-',
  process(node) {
    node.setAttribute(this.prefix + 'id', node.id);
  }
};
document.querySelectorAll('.item').forEach(handler.process, handler);

这里如果第二个参数不写 handler，回调里的 this 就会指向 undefined（严格模式）或者全局对象，那样 this.prefix 就直接报错了。这个细节容易忽略，但真的是排错时最让人抓狂的一类问题——代码一点语法错误都没有，逻辑也看着合理，就是结果不对，最后发现是 this 丢了。

4. 实战意识：NodeList 相关的性能优化与浏览器兼容清单

4.1 尽量缓存 NodeList，避免重复查询

这是老生常谈，但真没几个人能坚持做到。每次调 document.querySelectorAll 都要走一遍完整的 CSS 选择器匹配，这个操作远比一次属性访问耗时。在一个循环里反复查同一个选择器，纯粹是在烧 CPU：

javascript复制// 不推荐
for (let i = 0; i < 100; i++) {
  const items = document.querySelectorAll('.item');
  items[i].style.display = 'none';
}

// 推荐
const items = document.querySelectorAll('.item');
for (let i = 0; i < items.length; i++) {
  items[i].style.display = 'none';
}

如果配合动态渲染框架（比如 React、Vue），组件更新过程中 DOM 结构频繁变化，频繁的查询更是雪上加霜。一次性缓存列表、统一操作，不仅能提升性能，还能减少很多因为“查询时机不同导致结果不同”的诡异 bug。

我个人习惯是，如果一个 NodeList 会在多个函数里被用到，就把它提到函数外部缓存，或者在模块初始化时一次性查询好。但这里有个前提：如果列表内容是动态变化的，就不能盲目缓存静态 NodeList，否则拿到的永远是旧数据。判断标准很简单——如果这段逻辑只关心“进入页面那一刻的节点集合”，就放心缓存；如果关心“任何时刻的最新节点”，就必须在每次处理前重新查询，或者使用动态 NodeList。

4.2 重排与重绘：操作 NodeList 中的节点时要注意的时机

NodeList 只是节点的集合，真正的 DOM 操作（改样式、改属性、增删节点）会触发布局重排和绘制。如果你在一个循环里频繁修改样式，比如：

javascript复制const cards = document.querySelectorAll('.card');
cards.forEach(card => {
  card.style.width = '100px';
  card.style.height = '100px';
  card.style.margin = '10px';
});

理论上浏览器会帮你合并同一帧的操作，但前提是你在同步代码块里连续修改。如果中间有异步操作、或者你把多次样式修改拆分到不同的事件回调里，浏览器就可能产生多余的重排。更聪明的做法是，先批量读取需要的数据（比如所有卡片的高度），再统一修改样式，避免“读-写-读-写”交替导致的重排风暴。当然对正常页面来说，几十个节点不敏感，但如果是一个大表格、长列表，这种优化就能明显感受到差异。

另外要注意，修改节点样式时尽量不要反复访问 NodeList 的 length 属性。某些浏览器里，动态 NodeList 的 length 访问会触发一次重新计算集合大小的操作，频繁访问会拖慢性能。一个简单的小优化是：

javascript复制const children = container.children; // HTMLCollection, 同理
const len = children.length;
for (let i = 0; i < len; i++) {
  // ...
}

4.3 哪些浏览器环境 NodeList 支持还不完善，以及如何降级

现代浏览器对 NodeList 已经非常友好，forEach、keys、entries、values、Symbol.iterator 统统都有。但老的运行环境总有些短板：

如果项目有老内核兼容要求，我的建议是统一走“先转数组再处理”的路线。用 Array.prototype.slice.call(nodeList) 这招兼容性最好，IE8 都能跑（在支持 querySelectorAll 的前提下）。缺点是代码稍显啰嗦，但这换取的是“写一次、哪儿都能跑”的安心感。

还有一种做法是利用 Babel 或 polyfill，给老环境补上缺失的方法。比如引入 core-js 的 dom collections polyfill，但维护成本稍高，项目大了还容易遇到 polyfill 冲突。所以我的意见是：能用原生基础方法解决就别引额外的依赖，for 循环 + length 访问永远是最保险的底牌。

4.4 除了 querySelectorAll，还有哪些隐蔽的 NodeList 来源

querySelectorAll 是大家最熟悉的，但开发中还有几个容易忽略的入口，遇到它们时要知道它返回的是什么类型，免得顺手当成真的数组使用出现异常。

• element.childNodes：动态 NodeList，上一节说过了。
• document.getElementsByName：动态 NodeList，常见于表单元素按 name 获取。
• TreeWalker 的某些遍历引用，尤其是你自定义 NodeFilter 做节点过滤时，拿到的集合概念和 NodeList 一致。
• MutationRecord.addedNodes / removedNodes：这里返回的也是 NodeList，且是动态的，特别容易被人忽略。

比如监听 DOM 变化时：

javascript复制const observer = new MutationObserver(mutations => {
  mutations.forEach(mutation => {
    mutation.addedNodes.forEach(node => {
      console.log('新增节点', node);
    });
  });
});

注意这里的 mutation.addedNodes.forEach 就是 NodeList 的 forEach，如果环境不支持这个方法，这行代码也会崩。我在一个监控脚本里就踩过这个坑，当时运行环境是三星老系统自带的浏览器，mutation.addedNodes.forEach 直接报错。最后改用 Array.prototype.forEach.call 才稳下来。

所以说，凡是代码里出现 .nodeList.forEach(...) 的写法，都得在脑子里多问一句：我当前的最低兼容浏览器版本是什么？它有这个方法吗？

5. 实际项目里的综合经验：从排查到规划的高效路径

5.1 别把 NodeList 和 HTMLCollection 搞混

这俩太容易搞混了。getElementsByClassName、getElementsByTagName、getElementsByName 的一部分实现（有的返回 NodeList）返回的是 HTMLCollection，和 NodeList 是两回事，虽然表现很相似。

核心区别在于：

• HTMLCollection 一定是有 id 或 name 属性的元素才能用 namedItem 按名字快速访问，NodeList 没有这个接口。
• HTMLCollection 一定是动态的，NodeList 可能是静态也可能是动态（取决于 API）。
• HTMLCollection 只有 length、item() 和 namedItem()，没有 forEach，遍历基本只能靠 for 循环或转数组。

为什么这两个对象会同时存在？简单说，HTMLCollection 是更早的规范，专门针对 HTML 文档里的元素集合；NodeList 是更通用的节点集合，不只包含元素，还可能包含文本节点和注释节点。因此在 API 设计上，NodeList 更能反映 DOM 的真实结构，而 HTMLCollection 更偏向“只拿元素”这种实用需求。

实际写代码时，不想绕弯子就看返回类型：querySelectorAll 返回 NodeList，getElementsByTagName 返回 HTMLCollection。不管哪种，最稳的遍历策略都是“先转数组或者老老实实用 for 循环”，别依赖对象自身的方法。

5.2 用“选择器字符串太长”攻击这个问题

还有个小细节：querySelectorAll 接受的选择器字符串不能太长，太复杂时某些浏览器会直接抛异常或者返回空集合。比如我用过类似这样的选择器：

javascript复制document.querySelectorAll('.app .main .content .list .item .active .bold');

层级太深、类名太长，解析效率会明显下降，在某些老浏览器里甚至报 SyntaxError。虽然这个报错不是 NodeList 本身的问题，但会让人误以为 NodeList 获取失败了。遇到这种情况，最好拆成两步：

javascript复制const list = document.querySelector('.app .main .content .list');
const items = list.querySelectorAll('.item.active.bold');

先用一个较短的路径拿到容器，再在这个容器内部做更精准的查询。这样既稳又清晰，还绕开了长选择器带来的兼容风险。

5.3 NodeList 能直接访问样式吗

不能。这个问题我见过不少新同学踩坑——想给某个 NodeList 里的所有节点改样式，直接写：

javascript复制document.querySelectorAll('.item').style.color = 'red'; // 不行

然后惊讶地发现没效果。因为 style 是元素对象的属性，不是集合的属性。你要么遍历：

javascript复制document.querySelectorAll('.item').forEach(el => {
  el.style.color = 'red';
});

要么转成数组再用 map 生成一个新的数组（但别忘了赋值这一步）：

javascript复制Array.from(document.querySelectorAll('.item')).map(el => el.style.color = 'red');

第二种里 map 回调改变了每个元素的样式，返回的是新数组，但因为没人接收所以白白废弃了，可读性也比较差，不如 forEach 直观。这点也侧面说明，先把 NodeList 转成真数组、再调用熟悉的数组方法，虽然思路没毛病，但操作语义上还是要想清楚你是在处理节点集合，而不是处理原始数据集合。

5.4 实际项目里更实用的“批量处理”封装

既然 NodeList 使用如此频繁、细节又这么多，我在项目里干脆封装了一个通用的小工具，统一处理“获取节点、遍历节点、批量修改”这三件事：

javascript复制function queryAll(selector, context = document) {
  const list = context.querySelectorAll(selector);
  return Array.prototype.slice.call(list);
}

function forEachNode(selector, fn, context = document) {
  const nodes = queryAll(selector, context);
  nodes.forEach((node, index) => fn(node, index));
}

使用起来：

javascript复制forEachNode('.item', (node, index) => {
  node.dataset.index = index;
  node.classList.add('processed');
});

这样封装的好处有两个：一是 queryAll 返回的是真正的数组，后面想用什么数组方法都不受限制；二是如果以后想替换成别的查询引擎（比如用 XPath），只需要改 queryAll 内部实现，不需要改动其他业务代码。这类小工具在项目里非常实用，尤其是页面里大量使用原生 DOM 操作的时候，能省去很多“每到一个新文件都要重新记住 NodeList 怎么处理”的心智负担。

6. 一个极易忽略的大坑：NodeList 中的异步引用与内存释放

6.1 动态 NodeList 持有会让 GC 无处下手

这块算是我自己做性能排查时挖出来的东西。一个页面里如果长期持有一个动态 NodeList，尤其是一个容器节点特别多、DOM 频繁变化的页面，这个 NodeList 会保持对底层 DOM 节点的引用。就算你从 DOM 中移除了某些节点，只要这个 NodeList 还在某个变量里活着，这些节点就永远不会被垃圾回收。随着 SPA 页面不断切换，旧的容器、旧的子节点全部因为一个“不小心缓存的 NodeList”而卡在内存里，页面越来越慢，最后内存飙高甚至卡死。

我之前排查过一个线上管理后台越用越卡的问题，最后定位到原因就是某个全局变量存了一个 childNodes 的引用，每次进入新页面都更新，但旧页面的节点因为还被这个动态 NodeList 引用着，全部无法释放。解决方案很简单——不使用的时候把变量置为 null，或者改成每次进入页面重新查询，不常驻缓存动态 NodeList。

6.2 异步操作与 NodeList 的快照问题

再配合 Vue/React 这类框架使用时，还有一个更隐蔽的问题：异步操作拿到的 NodeList 引用，在页面数据更新后可能已经指向了“脱离 DOM 的旧节点”。举个例子：

• 页面初始渲染了 10 个 .item
• 你执行 const items = document.querySelectorAll('.item') 拿到了静态 NodeList
• 然后触发一个异步请求，等响应返回时重新渲染了页面，新的 .item 变成了 20 个
• 但你手里的 items 还是 10 个旧节点，其中一部分甚至已经不在 DOM 中

如果你在异步回调里直接操作 items，会发现对部分节点的修改“看起来没生效”——因为它们是脱离文档的旧节点，改它们的样式虽然不报错，但用户看不到变化。这里有一个非常典型的场景就是点击加载更多之后做滚动定位、或给新加载的条目绑定事件，一不留神就拿到旧快照。

解决思路就一条：凡是异步操作后要对“当前最新 DOM”做操作，永远在回调里重新查询，不要依赖异步之前缓存的 NodeList。这是我踩过好几回才彻底长记性的教训。

6.3 框架中的 NodeList 与虚拟 DOM 的关系

现在大家写 React、Vue 的时候，往往不太直接和 NodeList 打交道，引擎内部帮你把 DOM 操作封装了。但如果你要在框架里操作原生节点（比如做第三方图表、Canvas 初始化、或者配合某些老插件），依然难免会遇到 NodeList。

以 Vue 为例，this.$refs 里返回的大多是单个元素或数组，偶尔也会出现 NodeList。比如：

vue复制<div v-for="item in list" ref="items">{{ item }}</div>

这种情况下 this.$refs.items 其实是一个数组（Vue 内部做了处理），但如果你直接用 document.querySelectorAll 而不用 refs，拿到的还是一个原生 NodeList——并不因为你在用框架就自动变干净。

所以我的建议是：在框架项目里尽量少用全局查询（querySelectorAll），改用框架提供的 ref 或 $refs 机制。这不仅能规避 NodeList 的各种边角坑，还能保证组件渲染后拿到的一定是最新的、受框架管理的节点引用，避免出现“节点脱离了文档”的问题。

说到底，NodeList 并不难，难的是在真实业务环境里识别它和数组的边界、静态和动态的差异、以及异步环境下的引用失效问题。把这些搞透，你会发现很多“明明代码没错却不工作”的怪现象，其实一开始就能避开。