在循环中直接 await 会导致串行执行、性能下降和逻辑错误；应改用 promise.all 并行处理无依赖异步任务，避免 foreach 中使用 async/await，并用 let/const 防止变量捕获问题，同时控制并发数防压垮服务。
在循环中直接用 await 处理异步任务，看似自然，实则容易引发性能问题或逻辑错误。关键不在于语法是否合法，而在于你是否真正控制了执行顺序和资源消耗。
别在 for 循环里逐个 await 独立请求
当多个异步操作彼此无关（比如批量获取用户头像、拉取不同商品详情），却写成：
for (const id of ids) { const data = await fetch(`/api/item/${id}`); results.push(data); }
这会强制串行执行——等第一个请求完成，才发第二个，总耗时是所有请求时间之和。实际场景中，可能从 200ms 延长到 2s+。
✅ 正确做法：先发起全部请求，再统一等待结果：
- 提前创建 Promise 数组：
const promises = ids.map(id => fetch(`/api/item/${id}`)); - 用
Promise.all(promises)并行等待 - 再处理响应：
const responses = await Promise.all(promises); const results = await Promise.all(responses.map(r => r.json()));
forEach / map 里写 await 是无效的
arr.forEach(async item => { await doSomething(item); }) 看似在“等每个”，但 forEach 本身不关心回调返回什么，它立刻结束，不会暂停或等待内部的 Promise。
结果就是：函数调用后立即返回，异步操作在后台运行，你无法知道它们何时完成，也无法收集结果。
✅ 替代方案：
- 用
for...of循环 +await（适合需要串行、有依赖的场景） - 用
map生成 Promise 数组，再await Promise.all(...)（适合并行、无依赖） - 需要按序执行又想保留数组映射结构？用
reduce链式 await 或封装成工具函数
循环变量捕获错误：var vs let 的坑还在
在老式 for (var i = 0; i console.log(i), 100); } 中，输出全是 5 —— 因为 var 是函数作用域，i 被共享。
这个陷阱在 async/await 循环中依然存在，尤其当你在定时器、事件监听或闭包中引用循环变量时：
-
for (var id of ids) { setTimeout(async () => { const res = await fetch(`/api/${id}`); }, 0); }→ 所有请求可能都用最后一个id
✅ 解决方法很简单：
- 统一用
let或const声明循环变量（块级作用域，每次迭代独立绑定） - 或者显式传参：
setTimeout(async (id) => { /* use id */ }, 0, id)
大量并发可能压垮服务或浏览器
Promise.all 全部并发听起来高效，但如果一次发起 100 个请求，服务器可能限流、客户端可能内存暴涨、甚至触发浏览器连接数限制（通常 6~10 个同源并发）。
✅ 更稳妥的做法：
- 限制并发数，例如用
p-limit库或手写分批逻辑 - 对敏感接口加退避机制（如指数退避重试）
- 根据业务容忍度选择串行、分组并行（如每 5 个一批）或带节流的流水线
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
