forEach 不支持 await，因它同步执行且回调不等待 Promise 完成；所有异步操作并发发起，无法中断，后续代码立即执行；需按串行选 for...of，按并行选 Promise.all。
因为 forEach 的设计初衷就是同步遍历，它不关心回调里返回什么，也不等待 Promise 完成。你在回调中写 await，只是让那个回调函数内部“暂停”了一下，但 forEach 本身早已执行完毕，继续往下走了。
forEach 不会等待异步回调结束
它只是按顺序调用每个回调函数，然后立刻进入下一次迭代。即使你写了 await someAsyncFn(item)，forEach 也不会等这个 Promise resolve 就继续跑下一个元素——相当于启动了一堆“火后不管”的任务。
- 所有异步操作几乎同时发起，没有串行约束
- 循环体外的代码（比如
console.log('完成')）会在任何异步结果出来前就执行 - 无法用
break或return中断整个遍历流程
为什么看起来像“await 生效了”，其实没生效
你在回调里加 await，确实会让该回调内部的后续语句延后执行，但这个“延后”只对当前回调有效。由于 forEach 不收集、不等待这些回调的返回值，整个遍历过程仍是同步推进的。
- 例如：5 个耗时不同的请求，
forEach会瞬间发起全部 5 个，谁先完成谁先输出，顺序完全不可控 -
isFind = true这类状态更新可能在所有循环打印完index后才发生
如何快速判断你掉进了这个坑
出现以下任一现象，基本可以确认是 forEach + await 导致的逻辑错乱：
- 预期“一个接一个处理”，结果所有请求并发发出
- 循环结束后立即执行了后续逻辑，但异步结果还没回来
- 想用
break提前退出，却发现根本停不下来 - 调试时发现
console.log输出顺序和代码书写顺序完全相反
替代方案要按需选，不是越新越好
真正解决问题，关键不是换语法，而是明确你要的是“串行”还是“并行”：
- 需要严格顺序、依赖上一步结果 → 用
for...of或传统for循环，配合await - 多个请求彼此独立，只关心最终全部完成 → 用
map生成 Promise 数组，再await Promise.all(...) - 既要并发控制数量，又要保证顺序 → 考虑
p-limit这类工具库，避免手动管理复杂度
