forEach 中写 await 不起作用，因其同步遍历机制不等待 Promise 兑现；应改用 for...of 实现串行、Promise.all 实现并行，或手动分批控制并发。
在 forEach 中写 await 看起来像在“等”，其实根本没等——它既不串行，也不可控，并发行为完全失控。问题根源不在 await 本身，而在于 forEach 的同步遍历机制：它只管调用回调，不管回调里返回的是不是 Promise。
为什么 forEach 里的 await 不起作用
forEach 是纯同步方法，内部用类似 while 的循环逐个执行回调，调用完立刻进下一轮。即使你写了 async (item) => { await fetch(item) }，也只是立即返回一个 pending Promise，forEach 完全不关心、也不等待它兑现。
- 所有异步请求几乎同时发出，变成无节制并发
-
console.log('完成')在第一个请求刚发出去就执行了 - 无法用
break或return提前退出循环 - 某个请求报错，其他请求照常运行，错误也难统一捕获
串行执行：用 for...of 替代 forEach
需要任务按顺序一个接一个执行（比如上一步结果是下一步输入），就该用 for...of。它天然支持 await，每轮都等前一个异步操作结束再继续。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 可随时加
if (condition) break或return中断 - 单次或整个循环都能用
try/catch包裹，错误清晰可控 - 语义明确，代码意图一目了然
并行执行：用 map + Promise.all
如果任务彼此独立（如批量拉取用户头像、校验多个字段），就该让它们一起发、一起收。用 map 创建 Promise 数组，再用 Promise.all 统一等待：
立即学习“Java免费学习笔记（深入）”；
- 性能更好，总耗时接近最慢那个请求，而非全部相加
- 任一失败会导致整体 reject；如需容错，改用
Promise.allSettled - 不能中途终止，也不能逐个处理中间状态
控制并发数：手动分批 + for 循环
既不想全量并发压垮后端，又不愿完全串行太慢？可以自己实现分批逻辑，比如每次最多并发 3 个请求：
- 把大数组切片，每批用
Promise.all处理 - 批与批之间用
await隔开，形成“并发+节流”混合模式 - 比第三方库更轻量，也更容易调试和定制
