怎么在JS reduce中正确处理Promise异步串行操作

为什么普通循环无法满足串行，而需要关注 reduce？

在处理包含多个元素的数组时，如果每个元素都需要触发一次网络请求或耗时计算，很多开发者初次尝试会直接在 forEach 或 map 内部传入 async 函数。然而，forEach 与 map 是完全同步执行的遍历器，它们只负责依次调用回调，并不会等待回调返回的 Promise 决议。结果就是所有的异步任务在瞬间被并发触发。

在很多现实业务场景中，并发触发是不可接受的。最典型的就是第三方接口具有严格的频率限制（例如要求每秒最多处理 1 个请求，超频直接返回 429 错误）；另一个场景是有依赖状态的分布式事务、分片上传校验或工作流编排，前一个步骤的产物必须完整入库后，下一个步骤才能开始。

如图 1 所示，Promise.all 适合互不依赖且服务端承载力充足的场景；而一旦涉及受限资源或严格保序，我们就必须使用串行机制。此时，Array.prototype.reduce 凭借其天然的“状态传递”特性，成为了构建串行任务链的经典函数式载体。

初学者常踩的两个典型误区

在真正写出有效代码之前，了解为什么直觉写法会失效非常有帮助。

误区一：盲目在 reduce 回调前加 async，忽略累加器是 Promise

很多人写出的第一版代码往往长这样：

// 错误示范：直觉中的 async reduce
const list = [1, 2, 3];

const result = list.reduce(async (acc, item) => {
  const data = await fetchDetail(item);
  acc.push(data); // 运行时抛出 TypeError: acc.push is not a function
  return acc;
}, []);

这段代码在第二轮迭代就会直接崩溃。原因在于：一个被标记为 async 的函数，其返回值必然被包装成一个 Promise 对象。在第一轮结束后，回调返回的是 Promise<Array>，因此在第二轮迭代进入时，形参 acc 接收到的根本不是纯数组，而是一个处于 Pending 状态的 Promise！对一个 Promise 实例调用 .push() 自然报错。

误区二：遗漏初始值 Promise.resolve()

如果省略了 reduce 的第二个参数（初始值），JavaScript 引擎会将数组的第 0 项作为累加器的初始值，并从第 1 项开始循环。如果数组项是普通数值或字符串，由于它们没有 .then 方法，后续的链式调用会瞬间失败；即使数组项是函数，这种隐式初值也会让第一步脱离整体流水线控制，失去时序保证。

标准解法一：纯 Promise 链式构建（函数式风格）

理解串行最纯粹的方式是将其还原为基础的 Promise 链。我们让累加器保存上一次的 Promise，每一轮迭代通过 chain.then(...) 把新的异步动作追加在链条末尾。

1. 仅关注执行顺序（无需收集每步结果）

假设我们只需要依次执行一系列打印或写入操作，不需要保留中间返回值：

function delayLog(msg, ms) {
  return new Promise(resolve => {
    setTimeout(() => {
      console.log(`[完成] ${msg} (${ms}ms)`);
      resolve();
    }, ms);
  });
}

const tasks = [
  () => delayLog("步骤一：初始化环境", 300),
  () => delayLog("步骤二：拉取远程配置", 200),
  () => delayLog("步骤三：同步本地缓存", 100),
];

// 核心串行结构
tasks.reduce((promiseChain, currentTask) => {
  return promiseChain.then(() => currentTask());
}, Promise.resolve());

示例运行输出：

// 示例输出（明确标注）：
// [完成] 步骤一：初始化环境 (300ms)  -- 300ms 后打印
// [完成] 步骤二：拉取远程配置 (200ms)  -- 接着等待 200ms 后打印
// [完成] 步骤三：同步本地缓存 (100ms)  -- 接着等待 100ms 后打印

2. 既要保证串行，又要聚合每一步的结果

若需要把每个任务的处理结果汇总成一个数组返回给调用方，我们需要在 .then() 中同时接收累加的数组，并在当前任务完成时将其合并后返回：

function fetchScore(id) {
  return new Promise(resolve => {
    setTimeout(() => resolve({ id, score: id * 10 }), 150);
  });
}

const userIds = [101, 102, 103];

// 收集结果的串行 reduce
const serialScoresPromise = userIds.reduce((chain, id) => {
  return chain.then(accResults => {
    return fetchScore(id).then(singleResult => {
      // 使用 concat 或 push 维护列表，避免直接改变可能引起并发混淆的外部变量
      return accResults.concat(singleResult);
    });
  });
}, Promise.resolve([]));

serialScoresPromise.then(allScores => {
  console.log("最终汇总结果：", allScores);
});

标准解法二：reduce 配合 async/await 累加

如果你更倾向于编写符合现代风格的 async/await 代码，同样可以在 reduce 中使用它，但前提是必须正确处理作为 Promise 传入的累加器。

async function runSerialWithAsyncReduce(items) {
  // reduce 返回的是链条末端的那个 Promise，因此外部需要 await
  const finalResults = await items.reduce(async (previousPromise, item) => {
    // 关键第一步：先等待前序所有任务沉淀出的结果
    const acc = await previousPromise;

    // 关键第二步：执行当前项的异步任务
    const currentResult = await fetchScore(item);

    // 关键第三步：组合最新结果返回，成为下一轮的 previousPromise 承载内容
    return [...acc, currentResult];
  }, Promise.resolve([]));

  return finalResults;
}

// 执行示例
runSerialWithAsyncReduce([201, 202, 203]).then(console.log);

异常处理与控制流分支：短路中断 vs 容错降级

在实际网络环境中，某一个串行任务失败（如 500 报错或超时）是常见现象。处理异步串行时，必须根据业务目标明确选择两类异常策略：

策略 A：短路熔断（Fail-Fast）

只要中间任意一步发生错误，后续任务应当立刻终止，整条链路直接抛出异常。在 Promise 链条中，默认行为就是短路传播：任何一个步骤返回 reject 状态，下游的所有 .then() 都会被跳过，控制权直接转移给末端的 .catch()。

// 短路中断演示：任一任务失败则终止整条流水线
const tasksWithFail = [
  () => Promise.resolve("任务1 成功"),
  () => Promise.reject(new Error("任务2 接口超时熔断")),
  () => Promise.resolve("任务3 不应被执行"),
];

tasksWithFail.reduce((chain, task) => {
  return chain.then(results => task().then(res => [...results, res]));
}, Promise.resolve([]))
.then(res => console.log("全部成功：", res))
.catch(err => console.error("流水线已中断：", err.message));

// 示例输出（明确标注）：
// 流水线已中断： 任务2 接口超时熔断

策略 B：容错降级（Serial AllSettled）

在批量同步资产或更新状态时，往往要求即使某个条目失败，剩下的条目仍必须接着执行，最后输出一份完整的成功与失败清单。此时应该在单个任务自身绑定 .catch()，将错误包装成统一的数据结构：

// 容错收集模式：保证链路持续向下
const tolerantTasks = [
  () => Promise.resolve({ id: 1, status: "fulfilled", val: "数据A" }),
  () => Promise.reject(new Error("网络闪断")).catch(err => ({
    id: 2,
    status: "rejected",
    reason: err.message
  })),
  () => Promise.resolve({ id: 3, status: "fulfilled", val: "数据C" }),
];

tolerantTasks.reduce(async (prevPromise, task) => {
  const list = await prevPromise;
  const res = await task(); // task 内部已 catch，必定 resolve
  list.push(res);
  return list;
}, Promise.resolve([]))
.then(summary => console.log("执行报告：", summary));

方案权衡：reduce 串行 vs 现代 for...of + await

在 ES2017 正式引入 async/await 后，JavaScript 拥有了语法级的串行循环手段：for...of。在实际项目选型时，应该如何抉择？

总结与核心规范提炼

掌握在 reduce 中处理 Promise 异步串行，不仅能解决特定场景下的限频与保序问题，更是深刻理解 JavaScript 事件循环、Promise 链式决议以及函数式流式编排的重要途径。在日常开发中，请牢记以下三条核心规范：

1. 必须提供初始值：始终传递 Promise.resolve(initialAcc) 作为第二个参数，为整条异步流水线提供干净的启动锚点。
2. 正确解包累加器：若在回调中声明了 async，第一行务必先 const acc = await previousPromise;；若采用 .then() 链式风格，必须确保返回包含新任务的 Promise。
3. 明确界定错误边界：如果需要快速失败，直接让异常冒泡至最外层的 .catch()；如果需要全量收集状态，务必在单个任务内部将其封装为类似 allSettled 的状态对象，防止整链中途熔断。