JS await 真的只是“等一等”？聊聊那些让代码卡住的隐藏陷阱

写 JavaScript 前端开发久了，async/await 绝对是提升代码可读性的神器。以前回调地狱里层层嵌套的 .then()，现在能像写同步代码一样清晰流畅。但很多时候，代码逻辑明明是对的，运行起来却莫名其妙地卡顿，或者网络请求一个接一个慢得像蜗牛。这时候往往不是语法问题，而是对 await 的执行机制理解还不够深。

很多人有个误区，觉得用了 await 就万事大吉，实际上它是一把双刃剑。不当的使用会让原本可以并行的任务变成串行执行，直接拖垮整体性能。比如你需要从三个不同的接口获取用户信息、订单数据和配置项，这三个请求互不依赖。如果你把它们放在一个函数里用 await 依次等待：

const userInfo = await getUserInfo();
const orderData = await getOrderData();
const config = await getConfig();

这行代码看似优雅，实则浪费了大量时间。第二个请求必须等第一个返回后才发起，第三个又得等第二个。在移动端弱网环境下，这种延迟叠加会让用户感觉页面长时间处于“加载中”状态。正确的做法是利用 Promise.all 进行并发处理，让它们同时出发，谁先回来谁就先处理，总耗时取决于最慢的那个请求，而不是所有请求时间的总和。

除了性能陷阱，还有一个更隐蔽的坑：异常处理的遗漏。await 会把异步操作的结果直接抛出来，但如果这个异步操作失败了（比如网络断开或 API 报错），它不会像同步代码那样自然终止，而是会抛出未捕获的 Promise rejection。如果你在外面忘记包裹 try-catch，整个程序可能会静默失败，甚至导致后续逻辑错乱。

特别是在循环体中使用 await 时，错误处理更要小心。假设你要批量上传 10 个文件，如果在循环里直接 await upload(file)，一旦第 3 个文件上传失败，后面的 7 个就不会继续执行了，除非你把 await 放在 try-catch 内部单独处理。有时候为了不错过其他文件的上传进度，我们甚至需要把 catch 写在 await 那一行，保证错误被吞掉但不影响流程继续。

另外，关于 await 的使用范围，随着 ES2022 标准的普及，顶层 await (Top-level await) 已经允许我们在非函数作用域直接使用它。这在处理模块初始化依赖，或者在入口文件中动态导入某些重型资源时非常有用。你不再需要手动构建一个外层 IIFE 来包裹初始化的异步逻辑，代码结构更加扁平。但这并不意味着可以随意滥用，因为顶层 await 会阻塞模块的加载，如果逻辑复杂，依然会影响页面的首屏渲染速度。

最后提醒一点，不要在循环中盲目await。如果你需要在遍历数组时调用异步接口，尽量先将循环体内的 Promise 收集到一个数组中，统一用 Promise.all 处理，而不是直接在 for 循环里一行行等待。这不仅是为了快，更是为了防止内存堆积和栈溢出风险。

技术工具本身没有好坏，关键在于你怎么驾驭它。await 让异步代码变简单了，但也容易让人放松警惕。下次再遇到代码莫名变慢或报错的情况，不妨回头检查一下是否陷入了串行的泥潭，或者是不是忘了给潜在的异常穿上防护服。毕竟，写出跑得通的代码是基础，写出高效且健壮的代码才是本事。