JavaScript异步编程指南：Promise与async/await常见用法

明明只是发个网络请求，代码却嵌套得像俄罗斯套娃，稍微改个逻辑就得顺着缩进找半天括号。这种“回调地狱”是许多前端新手最头疼的时刻，也是从同步思维转向异步思维的第一道坎。

其实，现代 JavaScript 已经提供了非常优雅的工具来平整这些褶皱。只要掌握 Promise 和 async/await 的几个核心模式，你就能把那些层层叠叠的回调函数变成像读故事书一样顺畅的代码。

告别回调：用 Promise 链式调用理清顺序

在处理多个有先后依赖的异步操作时，比如先获取用户 ID，再根据 ID 获取详细信息，最后渲染页面，传统的回调写法会让代码向右无限延伸。

Promise 的出现让这一切变得线性化。每个 .then() 都代表下一步操作，返回值会自动包裹成新的 Promise 传递给下一个环节。你只需要关注当前步骤需要什么，以及下一步要做什么。

Promise链式调用流程

注意看，.then() 中返回的数据会直接作为下一个 .then() 的参数。如果中间某一步不需要处理数据，只是单纯等待完成，可以直接返回一个值或另一个 Promise。这种链式结构不仅消除了深层嵌套，还让错误处理可以统一收口到最后的 .catch() 中。

像写同步代码一样：async/await 的最佳实践

如果说 Promise 是把异步变成了链条，那么 async/await 则是把异步伪装成了同步。这是目前最主流的写法，因为它最符合人类的直觉：按顺序执行，拿到结果再继续。

使用 await 关键字时，函数必须声明为 async。这会暂停函数的执行，直到 Promise 解决（resolve）或拒绝（reject）。代码看起来就像普通的变量赋值，但背后依然在非阻塞地运行。

async/await 代码结构示意

这里有个细节值得注意：await 只能用在 async 函数内部。如果你在顶层脚本或普通函数中使用它，浏览器会报错。此外，虽然写法像同步，但它不会阻塞主线程的其他任务，UI 依然保持响应。

别被错误吞掉：统一的异常捕获机制

异步代码最怕的是“静默失败”。请求失败了，控制台没报错，页面也没反应，用户以为卡死了。在 Promise 时代，我们依赖 .catch()；而在 async/await 时代，try...catch 是最自然的搭档。

将可能抛出异常的异步操作包裹在 try 块中，任何被 reject 的 Promise 都会触发 catch 块。这不仅包括网络错误，还包括 JSON 解析失败等运行时错误。

try-catch 异常捕获结构

建议在实际项目中，尽量在最外层或业务逻辑入口处设置统一的 catch，避免在每个 await 后面都跟一个 try-catch，那样会让代码重新变得臃肿。对于非关键性的异步任务，可以单独处理错误，而不影响主流程。

提速关键：并行执行而非串行等待

很多开发者刚学会 async/await 后，容易陷入“无脑串行”的误区。比如页面上需要同时加载用户信息和商品列表，这两个请求互不依赖，但如果写成两个连续的 await，第二个请求必须等第一个完全结束才开始。

这浪费了宝贵的网络带宽和时间。正确的做法是使用 Promise.all()。它将多个 Promise 打包成一个，只有当所有请求都成功时才返回结果数组，任何一个失败则整体失败。

Promise.all 并行请求示意

如果你希望即使某个请求失败也不影响其他请求的结果，可以使用 Promise.allSettled()。它会等待所有操作完成，无论成功与否，并返回每个操作的状态和结果。这在展示部分数据的场景中非常有用，比如一个模块挂了，其他模块依然正常显示。

避坑指南：常见的使用误区

尽管 async/await 很好用，但有几个陷阱容易踩。首先，不要在循环中随意使用 await。如果在 forEach 中使用 await，它并不会按预期等待每次迭代完成，而是会并发启动所有异步操作，且无法保证顺序。如果需要串行执行循环中的异步任务，建议使用 for...of 循环。

其次，忘记 return 是常见错误。在 async 函数中，如果你希望调用者能 await 这个函数的结果，必须确保函数内部返回了 Promise 或值。如果函数内部没有 return，默认返回 undefined 包裹的 Promise，这可能导致后续逻辑出错。

最后，混合使用 Promise 和 async/await 时要小心。虽然它们可以互操作，但在同一个逻辑块中混用两种风格的错误处理方式（.catch 和 try-catch）会增加维护难度。建议在一个模块或函数内保持风格一致。

掌握这些模式后，你会发现异步编程不再是噩梦，而是构建高性能应用的利器。下次面对复杂的异步逻辑时，先画一下依赖关系图，再决定是用链式调用、串行等待还是并行加速，代码自然会清晰起来。