真正提升并发请求性能的关键是让 await 等在 promise.all 启动所有任务之后再收口，而非循环中逐个 await；应先批量发起请求，再统一 await 收口，总耗时约等于最慢请求耗时。
真正提升并发请求性能的关键，不是堆 await，而是让 await 等在正确的位置——等 Promise.all 启动完所有任务之后再收口。
先并发启动，再统一 await 收口
别在循环里写 await fetch()，那本质是串行；要先把所有请求“发出去”，再一起等结果。
- 错：逐个 await → 每次都要等上一个返回才发下一个，总耗时 = 所有请求耗时之和
- 对：先 map 出 Promise 数组 → 调用 Promise.all() → 再 await 它 → 总耗时 ≈ 最慢那个请求的耗时
- 示例：const [user, order, profile] = await Promise.all([fetchUser(), fetchOrder(), fetchProfile()]);
动态列表也一样处理
比如要查 100 个用户的邮箱，别 for 循环 await，而应：
- 先拿到用户列表：const users = await listUsers();
- 再批量构造请求：const emails = await Promise.all(users.map(u => fetchEmail(u.id)));
- 结果顺序严格对应 users 顺序，无需额外索引映射
按业务失败策略选方法
Promise.all 不是万能钥匙，得看你要什么结果：
- 全成功才继续（如支付前校验）→ 用 Promise.all()，配合 try/catch 整体兜底
- 部分失败也要汇总（如批量导出状态）→ 改用 Promise.allSettled()，过滤 fulfilled/rejected 分别处理
- 只取最快响应（如兜底接口、超时降级）→ 用 Promise.race()，常配合 timeout 包装器
加节流和超时，才算真正稳健
并发不是越多越好，不加约束反而拖垮体验：
- 限制并发数：用 p-limit 或手写分批逻辑，例如每次最多并发 6 个请求
- 防卡死：每个请求加超时，Promise.race([fetch(), timeout(8000)])
- 防内存爆：大数据量时分批 all，比如每 20 个一组，避免一次性加载全部响应体
不复杂但容易忽略：async/await 是语法糖，Promise.all 才是并发引擎。用对组合，性能翻倍只是起点。
