await本身不拖慢性能，真正影响效率的是使用方式：需避免串行瓶颈和内存炸弹，通过分批处理、并发请求、边拿边处理、主动让出主线程来优化。
await 本身不拖慢性能，真正影响效率的是怎么用它。关键不是少用 await，而是避免让它变成“串行瓶颈”或“内存炸弹”。优化核心是：分批、并发、让出主线程、边拿边处理。
分批处理，别一次全吞
面对几千条数据，直接 for 循环里 await 每一条，等于排长队等——总耗时 = 单条 × 条数。应该按固定大小切片，比如每批 30 条：
- 用 for + await 串行拉批：逻辑简单、易调试，适合对顺序敏感或服务端限流严的场景
- 用 Promise.all 并发拉多批：比如同时发起 4 批请求，但需限制并发数（3–5 个为宜），防压垮连接池或触发限流
- 批次大小选 20–50：太小 → 请求频繁、开销大；太大 → 单批失败重试成本高、内存占用飙升
能并行的，绝不排队
多个互不依赖的请求（如拉用户信息、配置、权限列表），逐个 await 是最常见也最浪费的写法：
- ❌ 错误写法：const a = await fetchA(); const b = await fetchB(); → 总耗时 = a + b
- ✅ 正确写法：const [a, b] = await Promise.all([fetchA(), fetchB()]); → 总耗时 ≈ max(a, b)
- 若允许部分失败，改用 Promise.allSettled，结果数组里每个对象都带 status 和 value/reason
边请求边消费，别攒着等
如果目标不是拿到全部再渲染，而是“来一批、画一批”，就别把所有数据 push 到一个大数组里：
- 每批 await 结束后，立刻调用处理函数（如 appendToDOM、writeToDB、transformBatch）
- 配合 AbortController，用户点击取消时可中断后续批次，响应更及时
- 避免内存峰值：10 万条数据，分 100 批处理，每批只存 1000 条，比一次性 load 全量省 99% 内存
主动让出主线程，防页面卡死
即使每批很快，连续几十次 await 后紧接大量 DOM 操作，也会挤占渲染时间，导致掉帧：
- 每处理 1–2 批后，加一句 await new Promise(r => setTimeout(r, 0))，让浏览器有机会重绘和响应用户操作
- 或用 queueMicrotask 把下一批调度延后到微任务队列末尾，节奏更轻量
- 对长列表加载、实时日志等场景，这种“喘口气”的设计比纯技术优化更能保流畅体验
