前端 Promise 并发控制与结果汇总

Promise 组合方法可以并发执行多个异步任务，但不同组合器的失败语义和结果结构不同。明确任务是否独立、是否允许部分成功以及服务器承载能力，才能选择合适的并发方式。

一、独立任务可以并发

如果多个请求互不依赖，逐个 await 会不必要地延长总等待时间。Promise.all 可以同时启动任务，并在全部完成后返回按输入顺序排列的结果。

const [profile, preferences, alerts] = await Promise.all([
    loadProfile(),
    loadPreferences(),
    loadAlerts(),
]);

Promise.all 任一任务拒绝时整体就会拒绝。其他任务不一定自动取消，因此有副作用的并行任务需要考虑取消和部分完成情况。

二、任务有依赖时保持顺序

若第二步需要第一步的结果，就应按依赖顺序执行。把有依赖的工作强行并行会造成数据错误，不能为了减少等待而忽略业务前置条件。

三、区分全成败和部分成功

Promise.all 适合所有结果缺一不可的场景。Promise.allSettled 会等待全部结束，并为每项返回成功或失败状态，适合仪表盘多卡片加载或批量操作的结果汇总。

const outcomes = await Promise.allSettled(tasks);
const successes = outcomes.filter((item) => item.status === "fulfilled");
const failures = outcomes.filter((item) => item.status === "rejected");

部分成功时，页面应明确哪些数据可用、哪些失败，而不是把所有任务包装成一个模糊的整体错误。

四、控制并发数量

一次启动成千上万任务会占用内存、连接和服务器资源。批处理可以限制同时运行的任务数；还可加入暂停、取消和进度统计。

async function runBatch(items, batchSize, worker) {
    const results = [];
    for (let index = 0; index < items.length; index += batchSize) {
        const batch = items.slice(index, index + batchSize);
        results.push(...await Promise.all(batch.map(worker)));
    }
    return results;
}

简单分批会等待一批全部完成后再启动下一批。若任务耗时差异很大，需要动态工作队列来维持并发上限，避免慢任务拖住整批。

五、处理结果顺序和幂等性

并发任务完成顺序不固定。若结果展示顺序有业务意义，应按输入索引关联结果，不能按完成先后直接追加。可重试任务还要确认重复执行不会造成额外副作用。

六、错误要带任务上下文

批量任务出错时应记录任务标识和阶段，便于定位。对用户展示汇总状态即可，不要把内部堆栈或敏感请求数据直接显示。

并发策略的选择依据

• 先画出任务依赖关系。无依赖的读任务可以并行，写任务若共享资源或顺序影响结果，应串行或按业务键分组执行。
• 使用 all 时要说明任一失败是否意味着整体不可用；使用 allSettled 时则为每个失败结果提供独立反馈，不能只统计成功数量。
• 设置并发上限要结合接口限流和浏览器资源。过高会增加失败，过低会延长完成时间，可通过真实任务耗时调整。
• 部分任务失败后是否重试，需区分可恢复网络错误与业务拒绝。重试不能把已成功的非幂等操作再次执行。
• 批次结果应映射回输入项目身份，并保留失败项。只按完成时间追加会改变业务顺序，也让用户难以判断哪个项目失败。

复核场景

仪表盘中的用户信息、消息摘要和统计卡片彼此独立，可以并行获取并分别显示失败；而订单详情依赖订单标识，应先取得标识再请求详情。若用户切换仪表盘期间旧批次仍在运行，应取消或忽略旧批次结果，避免混合两次查询的数据。

场景取舍补充

并发数量不是越大越快。接口限流、浏览器连接和用户设备都会限制有效并发；应从低并发开始测量成功率和总耗时，再逐步调整，而不是一次启动所有任务。

并发任务应支持整体取消和单项失败标记；如果用户离开页面，已经失去用途的批次不应继续消耗带宽和服务器资源。

对外显示的进度应基于已完成和失败的任务数，说明部分成功的含义。不能仅因 Promise 组合返回就推断所有远端操作已经持久化。

七、固定并发池而非整批等待

简单分批会等待一批中最慢的任务结束，才启动下一批。任务耗时差距大时，空闲槽位会浪费。工作池可以维持固定并发数：每个工作者从共享游标领取下一项，完成后继续领取，直到所有任务结束。结果应按输入索引保存，而不是按完成顺序追加。

并发池还要定义拒绝策略。若一个任务失败就停止领取新任务，已经开始的工作如何处理？若允许部分成功，失败项如何呈现和重试？这些问题应由业务含义决定，而非只看 Promise API。

八、取消、超时和背压

批量任务可以共享 AbortSignal，在页面离开或用户取消时通知尚未开始的工作。已经发送的请求能否真正中止取决于底层 API；无法中止时应停止后续队列并忽略过期结果。

过多并发请求会受服务器限流、浏览器资源和用户网络影响。为任务池设置队列上限，必要时按服务端返回的限流信号降低并发。退避重试应限制次数，并加入随机抖动。

九、聚合状态与用户反馈

页面可显示总数、已完成数、失败数和当前并发数。部分成功需要允许用户单独重试失败项，不能因为一个请求失败就丢弃全部成功结果。进度更新也要节流，避免每项完成都触发大范围重渲染。

十、异步组合的测试

使用可控 Promise 模拟任务顺序、失败和取消，验证并发上限从未超出，结果仍对应原项目，错误策略符合预期。测试要避免依赖固定睡眠来制造完成先后。

实施中的取舍与复核

并发控制的核心是规定同时运行多少任务，以及失败后是否继续。并发过高会占满连接、内存和服务端额度；过低则浪费可用吞吐。应按请求类别设置上限，并把排队时间与执行时间分开观测。任务进入队列后若用户已离开页面或取消批次，应能移除尚未开始的工作，避免无意义请求。

结果汇总要明确整体失败规则。全部成功才提交、允许部分成功并逐项呈现、或达到失败阈值就停止，是不同业务语义。并行执行时结果可能乱序，展示和持久化通常仍需按原输入索引对齐。Promise.all 在首个拒绝后会尽早拒绝，但其他已启动操作仍可能继续，因此不能把它当作自动取消机制。

面对大量任务，可采用固定工作池和有界队列，避免一次性创建数千个 Promise。失败重试要限制次数并带退避策略，重试前检查操作是否幂等以及是否仍在当前业务会话中。批量写入时保存成功结果和失败项，提供安全恢复，不要整批重放导致成功操作重复执行。

测试应覆盖任务数小于、等于和大于并发上限，某个任务失败、超时和取消，以及完成顺序不同的情况。可以注入可控的任务函数观察最大并发数，而不依赖真实网络。线上观测包括队列长度、取消比例和失败分布，帮助判断瓶颈在客户端调度、网络还是后端限流。

复核案例与后续维护

并发池中的任务如果永不结束，会占满所有工作位。为支持取消和超时，可为每项任务定义外部信号并在结束后释放资源；超时并不会自动停止底层工作，必须确认依赖支持取消，否则结果可能在之后仍到达。队列容量也要有限，达到上限时暂停生产、拒绝新任务或合并重复任务。

部分成功的业务需要清晰结果汇总。返回列表应包含每项原始标识、状态和可读错误，不能只提供一个整体成功布尔值。重试集合只包含可安全重试的失败项，并避免成功结果再次提交。并发限制可按服务器返回的限流信号动态降低，但要防止不同页面各自创建任务池导致总并发仍然失控。

观测最大并发、排队等待和重试后成功率，能够区分客户端过载和后端暂时故障。单元测试验证并发上限和结果顺序，集成测试验证服务端部分失败语义。批量操作完成后提供可复核的结果清单，用户可以理解哪些成功、哪些还需要处理。

总结

独立任务可并发，有依赖任务应顺序执行；all 和 allSettled 对应不同失败策略；大任务集需要限制并发并保留结果身份。并发设计必须同时考虑取消、重试和部分成功的业务语义。