关键在于区分场景选择工具：全部成功用预包装的Promise.all，至少一个成功用Promise.any，每个都要结果用Promise.allSettled，组合逻辑需分组封装，并发控制用Promise池。
处理多个 Promise 并行执行时的错误，关键不是“避开失败”，而是让失败不中断整体流程、不丢失上下文、也不掩盖问题。核心在于区分场景：是要求全部成功？至少一个成功？还是每个都要有明确结果？选对工具比写补丁更重要。
用 Promise.allSettled() 获取每个任务的确定状态
当你需要知道每一个异步操作（比如批量拉取用户资料、上传多张图片）到底成没成，且不能因某一个失败就放弃其余任务时，Promise.allSettled() 是首选。它不关心成败，只等全部结束，然后统一返回带 status 标记的结果数组。
- 每个结果对象含 status: 'fulfilled' 或 'rejected'，以及对应的 value 或 reason
- 适合做汇总上报、分情况重试、或 UI 上逐条展示成功/失败状态
- 注意：它不会自动抛错，所以
catch不会触发，要用then后手动判断并处理失败项
用 Promise.all() + 单个 catch 配合预包装防中断
如果业务逻辑要求“所有必须成功”，但又怕某个失败直接崩掉整个流程、导致后续清理逻辑（如关闭 loading、释放锁）没执行，那就别把 catch 放在 Promise.all() 外层完事。
- 更稳妥的做法：对每个 Promise 显式加
.catch(e => ({ error: e }))，让它失败后也返回一个“已解决”的值 - 这样
Promise.all()就不会被拒绝，你能在 then 里统一检查哪些项带 error 字段 - 既保住了并发性，又避免了未捕获 rejection 警告，还保留了错误细节
按语义分组再协调，避免竞态和错误遗漏
真实业务很少是“全要”或“全不管”。常见的是：A 或 B 任一成功即可；C 和 D 必须都成；E 是兜底必走通。这种组合逻辑不能靠一层 Promise.all() 解决。
- 先把每组封装成独立 Promise，例如
const abGroup = Promise.any([a(), b()]) - 再用
Promise.all([abGroup, cdGroup, ePromise])并发等待这三组结果 - 错误只会在某组内部被吞或传播，最终
catch捕获的是第一组失败原因，清晰可控 - 所有子任务从一开始就是并发的，不存在“AB 还没跑完 CD 先报错”这类时序陷阱
控制并发数量，从源头降低错误爆发风险
并发太多不仅拖慢响应，还会放大服务端限流、网络抖动、内存压力带来的失败率。100 个请求一起发，可能 30 个超时；限制到 5 个并发，成功率往往大幅提升。
- 用 asyncPool 类工具实现“Promise 池”，比如限制最多同时运行 3 个 fetch 请求
- 池中每个任务仍可独立
catch，失败不影响其他正在运行的任务 - 配合
allSettled或分组策略，既能控量，又能稳态处理结果
