如何利用 Promise.allSettled 在并发请求场景下确保获取每一个接口的具体返回细节
在前端开发中，处理多个并发请求是常见需求。当其中一个接口调用失败时，你是希望整个流程直接中断，还是希望清晰地了解每一个接口的最终状态？显然，后者对于数据监控和错误排查至关重要。JavaScript 中的 Promise.allSettled 方法正是为解决这一问题而设计。它能够在并发请求场景下，确保无论每个 Promise 是成功（fulfilled）还是失败（rejected），你都能获得其完整的状态与数据细节，从而生成一份全面的“请求诊断报告”。其核心优势在于：不会因单个请求失败而中断其他请求的执行，并且会完整保留所有请求的结果与错误信息。
为什么不用 Promise.all 或 Promise.race
那么，为什么推荐使用 allSettled，而不是更常见的 Promise.all 或 Promise.race 呢？关键在于它们的行为差异：Promise.all 遵循“一票否决”机制——只要数组中任意一个 Promise 被拒绝（reject），整个 Promise.all 会立即进入拒绝状态，导致其他所有已完成的请求结果丢失，你只能捕获到第一个错误信息。而 Promise.race 则是“竞速模式”，它只返回第一个状态敲定（settled，无论成功或失败）的 Promise 结果，完全无法满足“等待所有请求完成后再进行统一分析”的常规业务需求。
相比之下，Promise.allSettled 的设计更为周全和稳健。它返回一个数组，数组中的每个元素都是一个明确的对象，包含 status 属性（其值为 ‘fulfilled’ 或 ‘rejected’），并附带对应的 value（成功时的返回值）或 reason（失败时的原因）。这种数据结构，天然适合需要对批量请求结果进行逐一检查、精细化处理和错误上报的场景。
基础用法：拿到每个请求的原始状态和数据
Promise.allSettled 的使用方法非常直观。你只需将需要并发执行的所有 Promise 对象放入一个数组，然后传递给 Promise.allSettled 方法，最后遍历返回的结果数组，根据每个对象的 status 状态进行相应的逻辑处理即可。
const requests = [
fetch('/api/user'),
fetch('/api/orders'),
fetch('/api/settings')
];
Promise.allSettled(requests)
.then(results => {
results.forEach((result, index) => {
if (result.status === 'fulfilled') {
console.log(`请求 ${index} 成功`, result.value);
} else {
console.error(`请求 ${index} 失败`, result.reason);
}
});
});
结合 await 和解构，让逻辑更清晰
结合 ES7 的 async/await 语法，可以使异步代码的逻辑更加清晰、更接近同步编程的体验，也便于在获取到所有结果后，进行 JSON 解析等后续操作。这里需要特别注意一个关键点：使用 fetch API 时，请求成功（Promise 状态变为 fulfilled）并不代表 HTTP 响应状态码为 2xx。例如，遇到 404 Not Found 或 500 Internal Server Error 时，fetch 返回的 Promise 本身并不会进入 rejected 状态。因此，你需要在成功分支中手动检查 response.ok 属性或 status 状态码。
const apiCalls = [
fetch('/api/user').then(r => r.json()),
fetch('/api/orders').then(r => r.json()),
fetch('/api/settings').then(r => r.json())
];
const results = await Promise.allSettled(apiCalls);
results.forEach((res, i) => {
if (res.status === 'fulfilled') {
console.log(`✅ 接口 ${i} 数据：`, res.value);
} else {
console.warn(`❌ 接口 ${i} 异常：`, res.reason.message || res.reason);
}
});
实际项目中的关键细节
掌握了基础用法后，要在实际生产项目中稳健地应用 Promise.allSettled，还需要关注以下几个关键细节：
- HTTP 错误不等于 Promise reject：正如前文强调，使用 fetch 时，只有网络层面的异常（如断网、域名解析失败）才会导致 Promise 被 reject。对于 4xx 或 5xx 等 HTTP 状态码错误，Promise 状态依然是 fulfilled。因此，务必在 status 为 ‘fulfilled’ 的分支内，检查
response.ok或status字段，以准确判断业务层面的成功与否。 - 超时控制需额外封装：
Promise.allSettled本身不具备超时控制能力。如果接口有超时要求，需要为每个请求单独封装超时逻辑。常见的做法是使用AbortController接口配合setTimeout实现请求中止，或者将每个 fetch 调用包装成一个支持超时拒绝的 Promise。 - 避免未处理的 rejected Promise：如果某个请求在后续处理链中（例如，在
.then(r => r.json())解析 JSON 时）抛出了未捕获的异常，那么这个 Promise 最终会变为 rejected 状态。此时，其reason属性就是抛出的 Error 对象，你可以直接读取它的message、stack等信息用于调试和错误日志记录。 - 结果顺序严格对应入参顺序：这是
Promise.allSettled一个非常可靠且重要的特性。返回的结果数组中，每个元素的索引位置与传入的 Promise 数组的索引位置严格一一对应。这种确定的顺序映射关系，非常便于进行结果与源数据的索引匹配，或者用于批量更新 UI 列表中对应项的状态。
