JavaScript 异步编程的并发瓶颈，本质上并非语法层面的限制，而是资源调度管理不当——浏览器连接池的占用、内存的不断堆积、事件循环的过载，再加上后端接口的限流策略，这些因素共同作用，才是真正的性能瓶颈。解决这一问题不能仅依赖“更高级的 await”，而是需要主动进行分层控制：明确哪些操作应当并行、哪些需要限流、哪些必须排队、哪些可以降级，心里要有清晰的规划。
用 Promise.all 并行处理独立请求
当多个相互独立的异步操作（例如查询用户信息、拉取订单列表、读取系统配置）存在时，如果逐个使用 await 等待，总耗时将等于所有请求耗时的总和。改为使用 Promise.all 后，总耗时基本等于其中最慢请求的耗时，效率提升非常显著。
- ✅ 推荐写法：
const [user, orders, config] = await Promise.all([fetchUser(), fetchOrders(), fetchConfig()]) - ⚠️ 注意失败行为：Promise.all 一旦遇到任何一个 reject，就会整体中断；如果业务场景需要“尽力完成所有请求”，建议改用 Promise.allSettled()，结果数组中的每个元素都包含
status和value/reason，方便逐个处理 - ? 提示：Promise.all 返回的结果数组会严格按照传入顺序排列，与请求实际完成的先后顺序无关
用 p-limit 控制批量任务的并发数量
遍历 100 个 ID 去调用 API，如果每个都用 await 等待，那就是 100 次串行处理——后端压力巨大、前端响应迟缓、用户体验明显卡顿。真正有效的做法是限制同时运行的任务数量，而不是一次性全部发出。
- 引入 p-limit（轻量级、无额外依赖）：
import pLimit from 'p-limit'; const limit = pLimit(5) - 包装每个请求：
const results = await Promise.all(ids.map(id => limit(() => api(id)))) - 对于超大批量任务，可以先分批处理（比如每批 20 个），对每批调用 Promise.all，中间结果及时释放，内存压力更小
避免在循环中滥用 await
await 是暂停点，但并非所有地方都需要暂停。如果在 for 循环中盲目使用 await，就等于主动放弃并发能力，甚至还可能引发内存泄漏问题。不少开发者在这方面踩过坑。
- ❌ 错误示范：
for (const id of ids) { await fetch(`/api/item/${id}`) }→ 串行、低效，闭包还容易持有大对象 - ✅ 正确思路：如果逻辑不要求串行执行，就提前发起全部请求；如果确实依赖上一步的结果，才使用 await 链
- ? 关键判断：检查是否存在实际的数据依赖关系。例如“上报埋点”“更新 loading 状态”这类操作，完全可以与主请求并行执行，没必要等待 await 完成后再处理
设置超时与早期退出机制
有些场景无需等待所有请求完成即可响应，硬等反而拖慢整体体验。主动管理状态比被动等待更高效，具体有以下几种常见模式：
- 竞速模式：使用
Promise.race([p1, p2, p3])获取最先 settled 的结果（无论成功还是失败） - 超时保护：封装
Promise.race([apiCall(), timeout(3000)])，3 秒内未响应则 reject，避免请求挂死 - 早期退出：在循环处理中，一旦满足条件（例如找到第一个有效项，或者累计成功达到 3 个），直接 return，无需执行完所有任务
