应识别独立异步操作并用 Promise.all 并行发起，避免逐个 await 造成串行瓶颈；对非强依赖步骤用独立 try/catch 或 .catch 降级；循环中任务独立时改用 Promise.all；容错批量操作优先选 Promise.allSettled。
避免因错误使用 await 造成的性能串行瓶颈，核心在于识别哪些异步操作可以并行、哪些必须串行，并主动打破“一个 await 接一个 await”的惯性写法。关键不是少用 await，而是用对地方。
识别独立请求，改用 Promise.all 并行发起
多个请求之间无数据依赖、无执行顺序要求时，逐个 await 就是典型的串行瓶颈。浏览器或服务端会等第一个请求完成再发第二个，总耗时是各请求时间之和。
- 错误写法：每个 await 单独等待，请求依次发起
- 正确做法：先构造所有 Promise（如 fetch 调用不加 await），再用 Promise.all 统一等待
- 注意：Promise 数组定义那一刻，所有请求已发出；结果顺序与数组顺序严格一致，与响应快慢无关
区分错误类型，按需隔离失败影响
不是所有失败都需要中断后续流程。若某一步失败不影响整体业务（如拉取用户头像失败但基本信息可用），就不该让 reject 向上冒泡导致函数退出。
- 为单个 await 配独立 try/catch，失败后赋默认值或跳过，继续执行下一项
- 用 .catch(() => null) 或类似降级方式，让 Promise 自行消化错误，返回兜底值
- 避免把多个非强依赖步骤塞进同一个 try 块——一处出错，全盘停摆
避免在循环中滥用 await
for 循环里直接 await 异步操作，本质仍是串行。即使逻辑上需要遍历，也要判断是否真要等前一个完成再启动下一个。
立即学习“Java免费学习笔记（深入）”；
- 若任务彼此独立（如批量上传文件、批量发送日志），应收集所有 Promise 后 Promise.all 执行
- 若确实需顺序执行（如分页拉取且下一页 URL 来自上一页响应），才用 await + 循环，但需明确这是业务约束，而非误用
- 慎用 for-await-of：它隐式串行，仅适用于真正需要按序消费的 async iterator 场景
善用 Promise.allSettled 处理容错型批量操作
当你要同时发起多个请求，又希望“一个失败，其余照常完成”，Promise.allSettled 是比 Promise.all 更稳妥的选择。
- 它永远 resolve，返回每个 Promise 的完整状态（fulfilled 或 rejected）及对应结果或原因
- 适合初始化加载场景：配置、菜单、权限三者并行拉取，任一失败不影响其他两项生效
- 相比手动给每个 Promise 加 .catch，allSettled 更简洁、语义更清晰、错误信息更结构化
