JS异步遍历数组：for...of配合async/await的正确用法

在 JavaScript 中，如果需要对数组中的每一项执行异步操作，并严格保证按顺序“一个接一个”等待执行完毕（即串行处理），最标准且清晰的解决方案是使用 for...of 循环配合 async/await。很多开发者习惯使用的 Array.prototype.forEach、map 无法暂停循环等待异步结果，而 Promise.all 则是无序并发。本文将具体阐明 for...of 的标准写法、为什么它能按期等待、常见陷阱防范以及在何种场景下做出合理选型。

一、为什么常规方法会失效：常见陷阱与表现

在日常开发中，许多开发者在需要异步处理数组项时，直觉会写出类似下面的代码：

// 错误示例：forEach 无法等待异步操作完成
async function processUsers(users) {
  console.log('开始处理...');

  users.forEach(async (user) => {
    const res = await updateUserStatus(user);
    console.log(`更新完成: ${user.name}`);
  });

  console.log('所有用户处理完毕！'); // 会在 updateUserStatus 完成之前直接打印！
}

当执行上述代码时，控制台会首先打印出“开始处理...”，紧接着瞬间输出“所有用户处理完毕！”，最后才杂乱无章地打印出各个用户的“更新完成”。这与开发者预期的“处理完第一个用户，再处理第二个用户，最后报告全部完毕”大相径庭。

导致该现象的根本原因在于：Array.prototype.forEach 的内部规范实现是一个纯同步循环。它所做的事情仅仅是将数组的每一项作为参数同步传递给传入的回调函数。即便这个回调函数被 async 标记修饰，该回调在被调用时只会立刻返回一个 Promise 对象，而 forEach 源码本身对这个返回的 Promise 不做任何接收与 await 等待处理。于是循环体在极短时间内全量执行完成，外层的后续代码自然先行一步。

二、for...of 配合 async/await 的标准写法与完整示例

要在数组遍历中达成真正的串行等待，for...of 是 ES2015+ 推荐的标准语法。它必须置于一个 async 函数内部，在循环体内对返回 Promise 的表达式使用 await。

1. 基础标准写法

下面是一个模拟远程请求、带有网络延迟的完整可运行代码示例：

// 模拟一个异步耗时任务（如请求远程接口）
function fetchUserData(userId) {
  return new Promise((resolve) => {
    const delay = 500; // 模拟 500 毫秒响应
    setTimeout(() => {
      resolve({ id: userId, score: Math.floor(Math.random() * 100) });
    }, delay);
  });
}

// 正确示例：使用 for...of 串行遍历
async function loadAllUsersSequentially(userIdList) {
  console.log('--- 开始按顺序加载用户 ---');
  const results = [];

  for (const id of userIdList) {
    console.log(`正在请求用户 [${id}] 数据...`);
    // 关键点：await 会暂停当前 async 函数，直到当前 Promise 敲定
    const userData = await fetchUserData(id);
    results.push(userData);
    console.log(`用户 [${id}] 获取成功: 分数 = ${userData.score}`);
  }

  console.log('--- 全部用户加载完成 ---');
  return results;
}

// 执行测试
loadAllUsersSequentially([101, 102, 103]).then((res) => {
  console.log('最终结果聚合:', res);
});

预期输出顺序：

--- 开始按顺序加载用户 ---
正在请求用户 [101] 数据...
用户 [101] 获取成功: 分数 = 86
正在请求用户 [102] 数据...
用户 [102] 获取成功: 分数 = 42
正在请求用户 [103] 数据...
用户 [103] 获取成功: 分数 = 95
--- 全部用户加载完成 ---
最终结果聚合: [ { id: 101, score: 86 }, { id: 102, score: 42 }, { id: 103, score: 95 } ]

可以看到，在输出中，每次只有当当前用户的请求完全敲定之后，控制台才会进入下一次循环去打印下一个用户的请求提示。整个流程的执行步调完全在控制之中。

2. 需要数组索引（Index）时的写法

for...of 默认只输出数组的元素值。如果业务中既需要元素值，又需要当前的索引号（例如计算处理进度百分比），可以使用数组的 entries() 方法：

async function processWithIndex(items) {
  for (const [index, item] of items.entries()) {
    console.log(`正在处理第 ${index + 1}/${items.length} 个元素: ${item.title}`);
    await uploadItem(item);
  }
}

三、底层机制剖析：为什么 for...of 能够真正等待？

很多读者会好奇：同样是循环，为什么 forEach 不行，而 for...of 就可以？

这里的核心机制在于两者的语法地位与控制流执行上下文不同：

1. 回调隔离 vs 同一函数体上下文： forEach 是一个数组方法，它接收的是一个独立的回调函数。在回调函数内部写 await，它所暂停的仅仅是该回调函数内部的代码流，对于外层的 forEach 而言，它在同一个调用栈帧中继续同步执行下一个元素的递增与回调触发。
2. 语言级关键字与迭代器协议： for...of 不是函数调用，而是 ECMAScript 原生提供的语法结构（Syntax Structure）。它是直接展开在当前的 async 函数上下文之中的。 当执行到循环体内部的 await promise 时，JavaScript 引擎会直接将当前 async 函数挂起（相当于 Generator 的 yield 出让执行权），将控制权交还给事件循环。
3. 微任务通知与恢复： 只有当 promise 敲定并被微任务队列调度时，当前 async 函数才会从 await 的位置恢复执行，将返回值赋给变量，执行循环体剩余代码，然后再去调用数组迭代器的 .next() 方法拉取下一项。

四、异常处理与流程控制：try...catch 的位置考量

在真实业务场景中，异步请求难免会遇到网络超时、服务器 500 等异常。在 for...of 结构中，处理异常有两种截然不同的策略，取决于你的业务要求：

策略 1：某项失败即刻终止整个流程（放在循环体外部）

如果数组的后续项严重依赖前一项的处理成功，或者一旦报错就不应继续污染数据，应将 try...catch 包裹在 for...of 的外部：

async function processStrictBatch(orders) {
  try {
    for (const order of orders) {
      console.log(`正在扣减订单库存: ${order.id}`);
      await deductStock(order); // 若抛出异常，整个循环立刻中断
    }
    console.log('全部订单库存扣减成功');
  } catch (error) {
    console.error('某笔订单处理失败，流程已中断:', error.message);
    // 此处可执行事务回滚或报警逻辑
  }
}

策略 2：某项失败不影响其余项（放在循环体内部）

如果你希望即便某个用户的数据拉取失败，脚本依然能够坚韧地继续处理下一个用户，那么务必将 try...catch 放置在 for...of 的内部：

async function processFaultTolerant(files) {
  const successList = [];
  const failureList = [];

  for (const file of files) {
    try {
      console.log(`开始上传: ${file.name}`);
      const response = await uploadFile(file);
      successList.push({ file: file.name, response });
    } catch (err) {
      console.warn(`文件 [${file.name}] 上传失败，已跳过:`, err.message);
      failureList.push({ file: file.name, error: err.message });
      // 可选：使用 continue 明确跳过本轮后续操作
      continue;
    }
  }

  console.log(`处理完毕: 成功 ${successList.length} 个，失败 ${failureList.length} 个`);
  return { successList, failureList };
}

五、方案选型决策：什么时候该用 for...of？

for...of + await 虽好，但并非所有数组异步处理都要用它。因为它是串行的，处理总耗时将是所有任务耗时的线性累加（$T_{total} = \sum T_i$）。在没有顺序依赖时，串行会导致吞吐量低下。

我们可以根据以下三个关键维度来评估技术选型：

• 维度一：顺序依赖性。后一个任务的入参是否依赖前一个任务的返回结果？如果依赖，必须使用 for...of。
• 维度二：服务端速率限制（Rate Limit）。第三方接口是否有并发配额（如限制 1 秒最多调用 2 次）？如果高并发会触发 429 Too Many Requests，使用 for...of 并在每次循环后加适当的 sleep 是最稳妥的防爆策略。
• 维度三：任务体量与吞吐量。任务互不相干且服务端承受能力足够时，应该优先采用 Promise.all 或 Promise.allSettled 追求最快响应。

六、必须掌握的三个实践细节

1. 如何收集异步处理的返回值？

在 map 中我们可以直接返回新数组，而在 for...of 中，推荐在循环外部预先初始化一个结果数组，在每次 await 获得结果后手动 push 进去：

async function transformList(ids) {
  const finalResults = [];

  for (const id of ids) {
    const detail = await fetchDetail(id);
    finalResults.push({ id, ...detail });
  }

  return finalResults;
}

2. 在循环中支持主动中断与跳过

for...of 是真正的语言级循环，因此它完全支持 break（提前终止循环）和 continue（跳过当前项进入下一项），这是 forEach 根本无法做到的：

for (const item of items) {
  if (item.skip) {
    continue; // 直接跳入下一项，不执行后续 await
  }

  const result = await process(item);

  if (result.isFatal) {
    console.warn('检测到致命标识，提前终止循环');
    break; // 中断整个循环
  }
}

3. 并发场景下的标准写法回顾

为了加深对比，若确实需要并发处理（不需要等待前一项完成），正确的做法不是 forEach，而是使用 map 生成 Promise 数组，再用 Promise.all 等待整体结算：

// 正确的并发处理方式
async function fetchAllConcurrently(ids) {
  const promiseArray = ids.map((id) => fetchUserData(id));
  const results = await Promise.all(promiseArray);
  return results;
}