如何用 for await...of 遍历包含异步操作的数组列表-js教程-PHP中文网

for await...of不能直接遍历普通数组，因其仅支持实现[symbol.asynciterator]的异步迭代器；普通数组需用for...of+await顺序执行，或promise.all并发处理。

如何用 for await...of 遍历包含异步操作的数组列表

for await...of 不能直接遍历普通数组

很多人写 for await...of 时，下意识把一个普通数组（比如 const list = [fetch('/a'), fetch('/b')]）直接丢进去，结果发现代码同步执行、没等 Promise 完成就结束了——这是因为 for await...of 只对「可迭代的异步迭代器」有效，而普通数组的迭代器返回的是值，不是 Promise，更不是 AsyncIterator。

常见错误现象：TypeError: list is not async iterable 不会报（因为数组本身是可迭代的），但实际行为像同步 for...of，await 被忽略。

真正能用 for await...of 的对象：实现了 [Symbol.asyncIterator] 的对象，比如 ReadableStream、某些自定义异步生成器、或包装后的 Promise 数组
普通数组 + Promise 元素 → 需先转成异步可迭代形式，不能硬套
如果只是想“顺序等待每个 Promise”，更直接的做法是用 for...of + await，而非强求 for await...of

正确做法：用 for...of + await 顺序执行

绝大多数场景下，你想要的只是“一个接一个地发起请求并等它完成”，这时候最自然、最易读、最不容易出错的方式是：

const urls = ['/api/a', '/api/b', '/api/c'];
for (const url of urls) {
  const res = await fetch(url);
  const data = await res.json();
  console.log(data);
}

这个写法清晰表达了控制流意图：串行、阻塞、按序执行。它不依赖数组是否“异步可迭代”，也不需要额外转换。

AI舌诊面诊问诊医疗系统+诊疗商城系统源码

AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。

下载

性能影响：确实是串行，吞吐低，但语义明确；如需并发，请用 Promise.all，而不是强行用 for await...of
错误处理直接：在循环体内 try/catch 即可捕获单个请求失败，不影响后续
注意：必须在 async 函数内使用，否则 await 语法报错 SyntaxError: await is only valid in async function

真要用 for await...of？得先构造 AsyncIterator

如果你有特殊需求（比如流式处理大量数据、或与底层异步流对接），才需要手动构造异步迭代器。一个轻量封装示例如下：

function asyncMap(iterable, fn) {
  return {
    [Symbol.asyncIterator]() {
      const it = iterable[Symbol.iterator]();
      return {
        next() {
          const { done, value } = it.next();
          if (done) return Promise.resolve({ done, value });
          return Promise.resolve(fn(value)).then(v => ({ done, value: v }));
        }
      };
    }
  };
}

// 使用
const urls = ['/a', '/b', '/c'];
for await (const data of asyncMap(urls, u => fetch(u).then(r => r.json()))) {
  console.log(data);
}

这段代码本质是把同步迭代器桥接到异步迭代协议上。但它增加了理解成本，且容易在 next() 抛异常时漏处理错误。

不要复用这个模式去“优化”简单列表请求——得不偿失
asyncMap 返回的对象没有 return() 或 throw() 实现，遇到 break 或异常退出时无法清理资源
浏览器/Node.js 对 [Symbol.asyncIterator] 的支持已稳定，但调试时看不到原生数组的异步迭代痕迹，容易误判

并发 vs 串行：别用 for await...of 混淆概念

有人试图用 for await...of 实现“并发请求+按响应顺序处理”，这是误解。它既不自动并发，也不保证响应顺序与发起顺序一致——除非你显式控制 Promise 创建时机。

并发请求应优先考虑 Promise.allSettled() 或 Promise.all()，配合 map() 创建 Promise 数组
for await...of 在 ReadableStream 场景中才有“边接收边处理”的真实流意义，比如 response.body 解析
最容易被忽略的一点：即使你包装了异步迭代器，只要 next() 内部是 await fetch()，它仍是串行的；并发必须在 next() 外提前触发所有 Promise