Promise.all存在三大缺陷：一失败全中断、无并发数限制、不可取消；应依场景选用Promise.allSettled、p-limit等并发控制方案。
JavaScript 中的并发控制主要靠 Promise、async/await 和一些手动策略来协调多个异步任务的执行节奏。Promise.all 是最常用的并发执行工具，但它不是万能的——它在错误处理、资源占用、任务粒度和可控性上存在明显缺陷。
Promise.all 的核心缺陷
1. 一失败就全部中断（“全或无”语义）
只要其中一个 Promise reject，Promise.all 就立即 reject，其余仍在运行的任务不会被取消，但结果彻底丢失。你无法拿到已成功的部分结果，也无法继续等待其他任务完成。
- 例如：同时请求 10 个用户数据，第 3 个接口返回 404，Promise.all 直接抛错，后 7 个请求还在发，但你既得不到前 2 个成功结果，也收不到后 7 个的响应。
2. 缺乏执行数量限制（容易压垮服务或浏览器）
Promise.all 会一次性启动所有 Promise，如果并发量大（比如 100 个 API 请求），可能触发浏览器连接数限制、服务端限流或内存飙升。
- 现代浏览器通常对同一域名并发请求数限制在 6~10 个；Promise.all([...Array(100).keys()].map(i => fetch(`/api/user/${i}`))) 会瞬间发出近百个请求，多数被排队或拒绝。
3. 无法中途取消或暂停
ES2024 之前，原生 Promise 没有 cancel 方法，Promise.all 返回的 Promise 也不支持取消。即使你不再关心结果，底层异步操作（如 fetch、setTimeout）仍继续运行，造成资源浪费。
立即学习“Java免费学习笔记（深入）”；
更实用的并发控制替代方案
✅ 使用 Promise.allSettled 替代 Promise.all（解决失败中断问题）
它等待所有 Promise 结束（无论 fulfilled 或 rejected），返回每个结果的状态数组，便于做差异化处理：
const results = await Promise.allSettled([
fetch('/api/a'),
fetch('/api/b'),
fetch('/api/c')
]);
results.forEach((r, i) => {
if (r.status === 'fulfilled') console.log(`✅ ${i}:`, r.value);
else console.warn(`❌ ${i}:`, r.reason);
});
✅ 用 p-limit 或手写批处理实现并发数限制
控制同时最多执行 N 个 Promise，其余排队等待：
- 使用 p-limit 库：
import pLimit from 'p-limit'; const limit = pLimit(3); const promises = urls.map(url => limit(() => fetch(url))); - 手写简易版：用队列 + 计数器维护 running 数量，resolve 后启动下一个待执行任务。
✅ 需要取消能力？配合 AbortController（fetch）或封装可取消 Promise
fetch 支持 signal，axios 支持 cancel token，自定义 Promise 可通过闭包保存 resolve/reject 并暴露 cancel 函数。
什么时候该避免 Promise.all？
当你的场景满足以下任一条件时，应主动绕过 Promise.all：
- 任务之间无关，且单个失败不应影响整体流程（选 allSettled）
- 任务量大或资源敏感（如批量上传、爬取、大量 API 调用）→ 加并发限制
- 需要超时控制、重试、取消、进度反馈 → 用 Promise.race + 封装，或专用库（p-retry、p-timeout）
- 任务有依赖顺序或需流式处理（如分页拉取）→ 改用串行或 while 循环 + await
