2026年了，批量补数据用 forEach 里写 await，为什么请求全发出去才等结果？

2026 年做批量补数据时，forEach 里的 await 不会让循环等待，根因不是 await 失效，而是 forEach 从不消费回调返回的 Promise。它把每个 async 回调按同步函数调用一遍，回调内部返回的 Promise 没人接，循环自然先往下走。想让循环真的等异步：需要顺序就用 for…of 串行；不需要顺序且能承受并发就用 map 配 Promise.all；服务端有限流就按批切开，批内并行、批间等待。选错通道，常见代价是顺序错乱、接口限流或页面数据不完整。

为什么 forEach 里的 await 看起来没生效

理解这件事，抓住一个区分：函数被调用是同步发生的，异步任务完成是将来发生的。async 回调一被调用，内部代码会跑到第一个 await，然后返回一个 Promise；这个 Promise 什么时候完成、会不会失败，取决于有没有人接它。forEach 的实现里没有 await，也不看返回值，于是每一轮都被启动，却没有一轮被等待。

连带后果有两个：async 回调里抛出的错误会变成 rejected Promise，forEach 接不住，容易触发 unhandledrejection，控制台报错但业务流程照跑；await 写在 forEach 回调里语法合法，编辑器不报警、运行也不报错，往往到联调或上线后才暴露。排查时容易先怀疑接口和网络，实际是遍历方法选错了。

• forEach 返回值是 undefined，回调里写 return 不参与控制流。
• break 与 continue 在 forEach 里都不可用，要中途停下得换 for 配 break，或改用 some / every。
• async 回调一律返回 Promise，即使没有写 return，这一点常被忽略。

按顺序还是按并发：2026 年常见的四条通道

把数组异步遍历拆成四条通道，划分依据只有两个问题：要不要保证执行顺序，要不要限制同一时刻的并发数量。顺序与并发定下来，写法基本就定了。

1. 串行等待：for…of 配 await。每轮等上一轮完成再进入下一轮，顺序确定，总耗时约等于各条之和。
2. 并行等待：map 配 Promise.all。先把任务全部发出去再统一等结果，总耗时接近耗时较长的那一条。
3. 并行容错：map 配 Promise.allSettled。并发行为同上，但某一条失败不会让整批中断，适合部分失败可接受的批量操作。
4. 流式消费：for await…of。用于异步迭代器、分页拉取或流式返回，边到边处理，不必先把全部数据攒在内存里。

判断顺序建议是：先问这批任务之间有没有依赖，有依赖就只能走串行；没有依赖再问服务端能扛多少并发，扛得住走并行，扛不住就用并行加分批；数据本身是流式到达的，才轮到流式消费。反过来先挑写法再想语义，返工概率更高。

交付现场：批量补数据为什么容易被限流

有一次订单列表要逐条补物流信息，约束是接口文档写明单账号并发有限、单条响应常见区间在 150–400ms、页面还要保留 loading 与失败重试。最初写法是 forEach 配 await，本意想做成串行，结果几十条请求同一时刻打出去，服务端限流返回一批 429，部分行直接空着，联调现场被叫停。

改法是把数组切成每批 3–8 条，批内用 Promise.all、批间用 for…of 等待，再补逐条失败重试和骨架屏。前后多花了大约半天到一天工时，返工主要花在核对接口限流规则和补异常态上。交付这类列表页时，我会把「一次循环要不要控制并发」写进联调清单，因为它不像样式问题那样一眼可见，往往压测或线上告警时才浮现。先核对接口并发承受能力与超时设置，再决定循环写法，比写完回头改省事。

串行、并行、分批的可核对对比

把几条典型路径放到一起比，差别主要在耗时曲线和瞬时压力，而不是代码行数。

• for…of 串行：20 条数据、单条约 100–300ms，经验区间总耗时约 2–6 秒；瞬时并发为 1，服务端压力小、顺序可控；某条失败会中断后续，需要自己写 try/catch 与重试。
• map + Promise.all 并行：同样 20 条，总耗时通常压到耗时较长那条附近，常见几百毫秒到 1 秒多；瞬时并发 20，服务端与浏览器连接数都可能吃紧；一条失败即整批 reject。
• 分批并行：常见按每批 3–10 条切，耗时与压力都居中，是列表补数据场景的常见折中，批次大小按接口文档或实测调整。
• 纯本地计算：不涉及网络时不必引入异步遍历，普通 for 循环更直接，也没有额外的 Promise 开销。

判断口径可以简化成一句：需要上一条的结果才能算下一条，就用串行；只需要全部拿到再统一渲染，就用并行或分批。反过来硬套，代价通常是首屏等待变长，或者服务端触发限流后整页数据不完整。

适用边界与不适用边界

这套判断适合有网络请求、且存在顺序或并发要求的批量处理：列表补数据、批量提交、分页拉取、流式接收。反过来也有明确的不用场景。

• 适合：批量独立查询；逐条存在依赖；分页或流式数据；需要主动控制并发以保护服务端。
• 不适合：纯同步数组计算，用普通 for 更直接；只触发不关心结果的埋点上报，强行串行等待反而拖慢主流程。
• 可以缓一缓：数据量在个位数、接口本身很快的场景，为统一写法引入分批框架，通常得不偿失。

边界句可以这样记：数组遍历里的 await 只对你自己写的循环负责，forEach、map、filter 这类数组方法不会替你等；凡是要等，就必须显式选择串行或并行。

常见问题

forEach 里写 await 会报错吗？

不会。语法合法，async 回调返回 Promise，forEach 不接收也不等待，所以不报错也不生效，现象是后面代码先跑。

for…of 里 await 是不是一定串行？

是。每轮等上一轮完成才进入下一轮，顺序确定；20 条各 200ms 时累计约 4 秒，总耗时更长。

想并行又要限制并发数，有没有简单做法？

把数组按每批 3–10 条切开，批内 Promise.all、批间用 for…of 等待，常见区间上兼顾速度和服务端压力。

遍历里 Promise.all 和 allSettled 怎么选？

必须全部成功才能继续的用 all；允许部分失败、还要逐条结果的用 allSettled，再统一处理失败项。

循环里每个 await 都调接口，怎么减少调用量？

先做批量接口或用缓存合并重复参数，其次考虑分批并发；只在循环里加 await 而不动接口，调用量不会下降。

2026 年再遇到「循环不等异步」，先确认回调是不是挂在 forEach 或 map 上，再判断这批任务要不要顺序。需要顺序就走 for…of 串行，不需要就分批并行，并把失败重试与 loading 一起写进验收项。数据量小、接口快的场景不必强行上分批框架；接口有限流时，先按平台文档核对并发上限，再定批次大小。