告别“回调地狱”：JS async/await 的真实用法与那些容易踩的坑

写前端久了，谁没经历过 .then().catch() 连成楼梯的噩梦？async 和 await 的出现简直就是救星，让异步代码看起来像同步一样直白。但很多开发者发现，用熟了之后，明明逻辑简单了，线上报错却变多了，或者性能莫名其妙被拖慢。这往往不是语法的问题，而是对异步本质的理解还停留在表面。

咱们先聊聊最关键的错误捕获。在 Promise 链里，最后的 .catch() 能兜住所有错误，但在 async 函数里，一旦某个 await 语句拒绝（reject），如果没有包裹在 try...catch 中，函数会直接中断抛出异常。这点特别隐蔽，尤其当你在事件监听器里调用一个没有错误处理的 async 函数时，控制台可能只会闪过一行红字警告，而程序看似正常跑完了。记得，每个独立的异步操作流，都要有明确的容错边界，不要指望上一层函数自动帮你吞掉所有错。

再来看个更常见的性能坑：串行执行导致的等待浪费。假设你要同时获取用户信息和订单列表，这两个请求互不依赖。如果写成这样：

const user = await getUser();
const orders = await getOrders();

实际效果是，发完第一个请求必须等结果回来，才发第二个请求。在网络波动大的情况下，总耗时变成两者之和。正确的姿势是用 Promise.all 包裹并发任务：

const [user, orders] = await Promise.all([getUser(), getOrders()]);

虽然代码行多了一点点，但并发请求能大幅缩短整体阻塞时间。很多人为了代码“整洁”牺牲了效率，其实 Promise.all 配合解构赋值同样优雅。

还有个容易被忽视的细节：async 函数的返回值机制。无论函数内部显式返回什么，async 函数本身总会返回一个 Promise 对象。如果你返回一个数字 5，外部拿到的其实是 Promise.resolve(5)。这意味着当你把 async 函数当作参数传递给其他高阶函数时，一定要记得是否需要加一层 .then() 处理，或者直接在外层再加一个 await。这种隐式的类型转换，有时候会导致 typeof 判断失效，排查 bug 时容易让人头大。

随着 ES2022 标准的普及，顶层 await 也变得可用。以前只能在函数内部暂停，现在在模块顶层也能直接挂起脚本加载，适合做初始化配置、数据库连接池预热等操作。不过要留意，这会影响整个模块的加载速度，建议仅在确有必要时使用，比如读取本地配置文件后再导出业务逻辑。

最后想说的是，工具终究是为场景服务的。并不是所有异步都需要 async/await。如果一个异步操作只是简单的触发而不关心结果，比如上报数据，完全可以直接使用 fire-and-forget 模式，不必强求 await 让它暂停流程。理解引擎背后的 Event Loop 机制比死记硬背语法更重要，只有搞清了代码究竟何时入队、何时执行，才能真正驾驭异步编程，而不是被它牵着鼻子走。