核心区别在于任务依赖关系与执行时机：串行await适合有依赖的线性流程，总耗时累加；promise.all适合无依赖的并行任务，总耗时趋近单个最长耗时。
多个 await 串行执行和 Promise.all 并行执行，核心区别不在“写法好看与否”，而在于任务是否相互依赖、是否能同时发起、以及整体耗时是否可压缩。性能差距在 I/O 密集型场景（如 API 请求、文件读取）中尤为明显——串行可能慢 3–5 倍。
串行 await：适合有依赖的线性流程
每个 await 都会等前一个 Promise 完成后再启动下一个，天然形成顺序链。它不是性能差，而是设计意图就是“一步接一步”。
- 适用场景：后一步必须用前一步返回的数据，比如先登录 → 拿到 token → 再请求用户信息 → 最后拉取权限列表
- 代码直观，错误可精准定位到某一步，调试方便
- 无法提速：10 个请求各需 200ms，串行总耗时约 2000ms（忽略网络波动）
Promise.all：适合无依赖的并行任务
所有异步操作在调用瞬间就同时发起，不等彼此。只要全部成功，就统一收结果；任一失败，整个立刻 reject（快速失败）。
- 适用场景：加载多个独立资源，如头像、配置项、公告、用户统计卡片等互不影响的数据
- 10 个同样 200ms 的请求，并行总耗时≈200ms（理论最优，实际略高）
- 内存开销低：内部通过引用共享，避免重复创建 Promise 实例
别踩坑：错误处理方式决定健壮性
Promise.all 的“快速失败”是双刃剑。如果某个请求失败不该阻断其余，就不能裸用 .catch() 包裹整个 all，而要提前兜底：
- 给每个 Promise 加 .catch(() => null) 或返回默认值，确保它总是 fulfilled
- 或改用 Promise.allSettled() —— 它不管成功失败，等全部 settle 后返回每个 Promise 的状态对象
- 串行 await 里 try/catch 是按步隔离的，但一个出错就中断后续，需手动加逻辑续跑（不推荐）
混合策略：并行 + 串行 = 真实项目常用解法
现实业务往往既有并行块，也有串行链。例如：
- 先并行拉取「用户基础信息」和「系统配置」（二者无依赖）
- 再用用户 ID 串行请求「最近订单」和「收藏商品」（都依赖用户 ID）
- 最后把所有结果合并渲染
这种组合既榨干并发能力，又守住数据依赖关系，比纯串行快，比纯并行稳。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
