Promise.allSettled 更适合收集全部请求结果，因为它始终 resolve 并返回每个 promise 的 status、value 或 reason，不因任一拒绝而中断；而 Promise.all 任一拒绝即 reject，丢失其余结果。
Promise.allSettled 为什么比 Promise.all 更适合收集全部请求结果
当多个接口请求中允许部分失败、且你仍需处理所有响应（包括错误）时，Promise.all 会因任一 promise 拒绝而直接 reject，根本拿不到其余成功或失败的结果；Promise.allSettled 则始终 resolve，返回每个 promise 的完整状态对象，这才是你真正需要的“全量反馈”能力。
典型场景：批量提交表单、并行校验多个字段、上报多条日志且不因某条失败中断其余。
-
Promise.allSettled返回的是Promise<Array<{status: 'fulfilled' | 'rejected', value?: any, reason?: any}>>，每个元素必有status字段 - 它不关心是否全部成功，只保证所有 promise 都 settle（即完成或拒绝），不会提前终止
- 浏览器兼容性需注意：IE 完全不支持，Chrome 76+、Firefox 79+、Safari 13.1+ 才可用；Node.js 12.9.0+ 支持
如何解析 Promise.allSettled 的返回值并区分成功与失败
返回数组里的每个对象必须显式判断 status，不能直接解构 value 或 reason —— 否则会报错（比如对 rejected 项访问 value）。
const results = await Promise.allSettled([
fetch('/api/user'),
fetch('/api/order'),
fetch('/api/invalid')
]);
results.forEach((result, index) => {
if (result.status === 'fulfilled') {
console.log(`请求 ${index} 成功`, result.value); // result.value 是 Response 实例
} else {
console.error(`请求 ${index} 失败`, result.reason); // result.reason 是 Error 或其他 reject 值
}
});
-
fulfilled项的value是你resolve的值（如fetch返回的Response对象） -
rejected项的reason是你reject的值（可能是Error，也可能是字符串、数字等） - 别漏掉
index或原始请求标识——否则你无法知道哪个 URL 或哪个数据项出了问题
和 fetch 结合时，为什么还要手动检查 response.ok
Promise.allSettled 只捕获 promise 的 settle 状态，不处理 HTTP 状态码。也就是说，fetch 即使返回 404、500，只要没抛出异常（比如网络断开），它仍是 fulfilled 状态，value 是一个 Response 对象——但它的 ok 是 false。
立即学习“前端免费学习笔记（深入）”；
- 常见错误：把
result.status === 'fulfilled'当作“接口调用成功”，结果拿到 404 的Response还继续.json()，导致后续解析失败 - 正确做法：在
fulfilled分支里加一层if (!response.ok)判断，并主动reject或归类为业务失败 - 示例中若想统一格式，可将
response.ok === false的情况也转为{ status: 'rejected', reason: new Error(...)}，方便上层统一处理
Promise.allSettled 在并发控制和超时处理中的限制
Promise.allSettled 本身不提供并发数限制或超时机制，它只是“等待所有 promise settle”。如果你发了 100 个 fetch，它就真等 100 个——哪怕其中几个卡死，整个数组就永远不返回。
- 必须配合
AbortController或封装 timeout promise（如Promise.race([fetch(...), timeout(5000)])）来防止单个请求阻塞整体 - 并发量大时建议用
Promise.allSettled+ 分批（如每 5 个一组），避免浏览器连接数限制或服务端限流触发 - 注意内存：大量请求同时 pending 会占用较多资源，尤其在低配设备或旧版浏览器中表现更明显
真正容易被忽略的不是语法，而是“settled 不等于成功，也不等于安全完成”——你得自己定义什么叫失败，然后在 fulfilled 分支里做二次判定，再决定是丢弃、重试，还是计入统计。
