从事件循环到状态机：深入理解 async/await 的异步编程实践

做了这么多年 JavaScript 开发如果要我选一个最值得花时间弄懂的特性我会毫不犹豫地选 async/await。它不是那种“会用就行”的语法糖而是现代异步编程里真正改变代码组织方式的基础设施。无论你是刚接触 Promise 的新手还是已经被回调地狱折磨过几年的老手这篇文章对 async/await 的分析都值得一看。我会从演进逻辑、底层原理讲到错误处理、并发控制和问题排查把我这些年踩过的坑、回读源码后的理解、以及反复调试沉淀下来的经验完整拆开来聊。先声明这篇文章不是 API 文档式的罗列。文档只会告诉你 async 函数要怎么写、await 后面要跟什么但它不会告诉你为什么有些代码“看起来对跑起来乱”。真正让你在工作里游刃有余的是理解它背后的运行时机制以及在真实业务场景里知道该在什么地方用什么姿势。1. 从回调地狱到 async/await异步方案演进中的关键设计1.1 回调和 Promise解决过问题也留下了新的别扭早期的 JavaScript 异步编程核心就是回调函数。一件事做完之后把结果交给另一个函数继续处理。单看这种模式其实还挺合理的问题是事情一多代码会像俄罗斯套娃一样一层套一层。我见过不少老项目里三层以上的嵌套回调是常态五层以上基本要靠缩进和注释才能认得出实际逻辑。这种代码最可怕的不是“难看”而是“可信度低”你不确定某个回调到底有没有被调用、被调用了多少次、内部抛出的错误到底有没有人接住。后来 Promise 出现了它把回调从“作为参数传进去”变成了“作为返回值拿回来”。这个转变是根本性的因为有了返回值你就能把异步操作像链条一样串起来用 .then().catch() 让代码从纵向嵌套改为横向展开。客观地说Promise 解决了数据流和错误流“没有明确路径”的问题。但 Promise 只解决了一部分问题一旦业务分支变多或者流程中间需要插一段条件判断.then() 链依然会写得很别扭。更常见的是为了一个中等复杂度的业务逻辑你要把一段代码拆成七八个具名函数然后在链条里来回调度。读起来其实并不轻松。之所以要从这段历史讲起是因为 async/await 不是凭空冒出来的它是对前面所有异步方案优缺点的回应。理解了它要解决什么你才知道为什么它值得被叫做“终极解决方案”。1.2 async/await 不只是语法糖它改变了代码的信任边界很多人第一次接触 async/await 的时候会觉得这就是“Promise 的语法糖”把 .then().catch() 变成了同步代码的模样。这个理解不能说错但太小看它了。语法糖改变的是写法async/await 改变的是思维模型。在回调时代你要时刻提醒自己这一段代码是异步的下一段代码不一定会按顺序执行。这种心智负担非常重尤其是代码规模变大之后人的短期记忆根本装不下这么多悬而未决的状态。而有了 await你在代码里看到的顺序就是实际执行的顺序“先请求数据再使用数据再更新界面”这三行代码读起来就是从上到下逻辑对应关系非常直接。你不需要再反复脑内翻译“这个 .then 里应该能拿到上一个 .then 的结果”。一句话async/await 让异步代码的信任边界从“靠脑补”变成了“靠语法保证”。我经常跟团队里的新人说如果你写异步代码时还在靠注释告诉别人“这里其实是异步的”那说明你还没有用好 async/await。这个方案之所以是现代的是因为它让代码的可维护性和正确性同时上了一个台阶别人能读懂机器能按顺序执行出错时的堆栈信息也远远清晰于回调时代。2. 原理拆解await 面前的事件循环与状态机讲清楚原理才能在真正出问题的时候知道往哪个方向排查。我知道很多人对原理不感兴趣但异步代码的 bug 基本上就藏在这些底层机制里。2.1 async 函数返回了什么Promise 包装规则一个 async 函数不管你在里面有没有写 return函数本身一定会返回一个 Promise。如果你 return 的是一个普通值它会被包装成 Promise.resolve(value)如果你 return 的是 Promise那么外层那个 Promise 就会跟着一起 settle如果你在函数里 throw 了异常返回的 Promise 会变成 rejected。这个规则看起来简单但有一个特别容易踩坑的地方如果 async 函数内部没有 await它仍然是异步的吗答案是“执行顺序上不算”。看这个例子async function doSomething() { console.log(同步执行); } doSomething(); console.log(外部代码); // 输出顺序同步执行 - 外部代码两个 console.log 是同步顺序跑完的只是 doSomething() 返回的那个 Promise 会自动 resolve 而已。这个认知非常重要async 关键字只负责“让函数返回 Promise 并且支持内部 await”它不会把函数体内的同步代码强制变成异步任务。真正让执行“切走”的是 await 那一行。理解了这一点你就不会看到一堆 async 函数就误以为它们全都在“后台执行”了。2.2 await 到底在等什么微任务与执行栈的切换要理解 await一定绕不开事件循环和微任务。我打一个比方你把代码的执行想象成只有一个窗口的奶茶店店员就是主线程顾客就是排队等待的任务。大多数时候一个顾客点完单、拿到奶茶、离开这个流程是同步的。但如果某个顾客说“我要等 10 分钟后再做”店员不能原地等他而是让他先去旁边等着然后服务后面的人。等那 10 分钟到了店员回头再来处理这位顾客。这里的“等 10 分钟”就是异步操作“把顾客重新叫回窗口”就是 Promise resolve 后触发微任务排队。await 做的事是把当前 async 函数的执行上下文先挂起来让出主线程等它 await 的那个 Promise settle 之后再把剩下的代码作为微任务重新排队进事件循环。所以 await 并不会真的阻塞住主线程它只是精准地控制了函数内部的执行顺序同时把线程让给了其他人。有一个新手特别容易混淆的点await 等待的时候外面的同步代码已经跑完了吗是的。如果在 async 函数外面还有同步代码那么当 async 函数执行到第一个 await 并挂起之后外面的同步代码会接着执行完之后事件循环才会去处理那个微任务来继续 async 函数。这个执行顺序不是你用 if 分支或写注释能绕过去的它是语言层面的规则。为了加深印象我们看一个经典例子async function test() { console.log(1); await Promise.resolve(); console.log(2); } test(); console.log(3); // 输出顺序1 - 3 - 2很多人第一次看到 1、3、2 这个顺序都很意外但理解了“await 会把后续代码挂到微任务队列”之后就觉得理所当然了。先执行 async 函数里第一个 await 之前的同步代码打印 1然后遇到 await把函数剩余部分挂起回到调用方执行外面的同步代码打印 3等同步代码跑干净事件循环处理微任务继续 async 函数剩余部分打印 2。2.3 编译视角async/await 的状态机本质如果你追溯到底层实现比如看某些转译器编译出来的代码你会发现 async/await 实际上被转换成了一个“状态机”。函数的执行不是一口气跑完而是被拆成多个状态初始状态、每个 await 之后的状态、结束状态。每到一个 await函数就把当前状态保存下来返回等 Promise 回来之后再根据保存的状态恢复执行。这个状态机模型解释了为什么“看起来像同步”的代码并没有真的阻塞它只是把一段函数切成了多个片段每个片段之间通过事件循环来衔接。从表现来看它有点像生成器函数配合迭代器。这也是为什么很多讲 async/await 原理的人会顺便提到生成器两者共享了“暂停/恢复”的底层机制。知道了这一层你再遇到“async 函数里 await 前后的变量值为什么是这样”这类问题心里就有了底因为每一段都是独立的执行片段共享的是函数作用域里的变量而执行时序完全由微任务队列控制。理解了状态机其实就抓到了 async/await 的七寸后面所有看起来玄学的执行顺序问题都能归约成“状态什么时候被恢复”。2.4 await 与 .then 的微妙差异不是每次都能无脑替换虽然 async/await 可以改写 Promise 链但你不能每次都用同样的心智去替换。举一个很容易出错的例子Promise.resolve(1) .then((x) x 1) .then((y) console.log(y)); // 2 (async () { const x await Promise.resolve(1); const y x 1; console.log(y); // 2 })();这个例子两者输出一样但设计上有区别。.then 链天然是“数据流管道”每一步的返回值作为下一步的输入容易写出函数式的简洁风格async/await 则是“顺序化执行流”更适合需要大量分支判断、循环、中间变量、以及跨步骤共享状态的复杂场景。如果你的业务逻辑本身就是“按顺序做几件事”async/await 更合适如果你要把一个数组里的元素逐个映射成异步结果.then 或 map 配合 Promise.all 可能更干净。选型不是因为你更熟悉哪个而是因为这几种方案的表达重点本来就不一样。3. 实操要点错误处理、并发控制与性能优化原理再熟工程上处理不好也白搭。这一部分是我在实际项目里验证过的经验可以直接参考。3.1 错误处理的三道防线async/await 时代最常见的错误处理模式就是 try/catch。但很多人写 try/catch 的位置不对。我见过在 async 函数里包一个巨大的 try/catch把整个业务逻辑全裹住然后 catch 里打一个 console.log 就完事。这种做法的问题在于一旦出了问题你只知道“某处失败了”完全不知道是哪一步、哪个请求、什么参数导致的排查成本高得吓人。我的习惯是采用三道防线在每一个真正可能出错的 await 调用旁边用 try/catch 捕获并附带上下文信息比如请求 URL、入参摘要。这个层面的错误要尽量携带业务语义是超时、是 404、还是数据格式不对。在 async 函数的最外层统一接住未被捕获的 rejected Promise保证任何错误都不会变成“静默失败”或全局的 unhandledrejection。对于需要给用户回馈的错误要提前设计好错误类型。不要什么都抛 Error(something wrong)建议至少区分业务错误比如用户没权限和系统错误比如网络超时这两类的处理策略完全不同。async function loadUserProfile(userId) { try { const res await fetch(/api/users/${userId}); if (!res.ok) { throw new Error(请求失败HTTP ${res.status}); } return await res.json(); } catch (err) { // 注意这里要改写成携带上下文的新错误而不是吞掉 throw new Error(加载用户资料失败userId${userId}原因${err.message}); } }还有一个细节永远不要在一个 catch 里只打印日志就完事。如果这个错误不应该被静默忽略就一定要继续往上抛让外层决定是给用户提示还是做降级处理。静默吞掉错误是异步代码里最隐蔽的坑之一它会让系统看起来“没事”其实内部早就烂成一锅粥了。3.2 串行与并行顺序 await、Promise.all、allSettled 的分工新手最常见的性能问题是把可以并行的请求一个个 await。比如要同时展示用户的基本信息和订单列表这两个接口之间没有依赖关系但如果写成const user await fetchUser(); const orders await fetchOrders();第二个请求要等第一个请求完全结束之后才会发出去总耗时是两个接口延迟的累加。正确的做法是用 Promise.all 让它们并发const [user, orders] await Promise.all([fetchUser(), fetchOrders()]);这样总耗时约等于最慢的那个请求。不过要注意Promise.all 是“全部成功才算成功”只要有一个失败整个 Promise.all 就 rejected 了。如果你希望即使某个请求失败其他请求的结果仍然有价值那应该考虑 Promise.allSettled它会等所有请求都结束再逐个告诉你每个请求成功还是失败。反过来如果几个请求之间有数据依赖比如先拿到用户 ID才能去查这个用户的历史订单那就老老实实用顺序 await。顺序 await 本身不是坏事符合业务逻辑的串行是必要的。真正的坑是把没有依赖的请求写成了串行白白多等了几百毫秒用户感知到的就是页面转圈更久在慢网络环境下体验特别差。3.3 超时与取消async/await 的短板与标准解法async/await 有一个天然的短板它不支持从外部取消一个正在 await 的操作。这是经常被忽略的问题。比如用户点击了一个按钮发了一个请求然后响应还没回来用户就跳转到了别的页面那个请求依然会在后台跑完而且代码还会继续执行接下来的步骤甚至可能去更新一个已经销毁组件的状态。最常用的解法是定时器配合 Promise.race 模拟超时function withTimeout(promise, ms) { return new Promise((resolve, reject) { const timer setTimeout(() { reject(new Error(操作超时超过 ${ms}ms)); }, ms); promise.then( (value) { clearTimeout(timer); resolve(value); }, (error) { clearTimeout(timer); reject(error); } ); }); }但这只是“超时后不再等待”并不能真正中断底层请求。如果你用的是 fetch还可以配合 AbortController 实现真正的取消const controller new AbortController(); const timeoutId setTimeout(() controller.abort(), 5000); try { const res await fetch(/api/data, { signal: controller.signal, }); const data await res.json(); } catch (err) { if (err.name AbortError) { // 这是超时/主动取消和普通请求失败区分开 } } finally { clearTimeout(timeoutId); }我建议在项目里建一个统一的请求封装把超时、取消、错误格式化都内置进去这样业务层就不用每次都重复写这一套也不会因为某个接口忘了加超时导致页面一直转圈。3.4 循环中的异步forEach、map、for...of 的真实差异数组循环里处理异步三者的行为差别极大也是最容易写错的地方。forEach 配合 async 函数特别容易踩坑。看这个[1, 2, 3].forEach(async (item) { await doSomething(item); }); console.log(done);这里 forEach 根本不会等待每个异步回调完成它会同步地“扫”完整个数组然后立刻执行后面的代码。上面的 console.log(done) 会在所有 doSomething 完成之前就打印出来。如果你以为这段代码会等三个 doSomething 全部完成后才打印那就错了。如果要等所有异步操作按顺序完成用 for...offor (const item of [1, 2, 3]) { await doSomething(item); }这段代码会一个接一个地执行全部完成之后才走到循环后面。它的特点是串行适合有依赖关系的批量操作。如果你追求并行用 Promise.all 配合 mapawait Promise.all([1, 2, 3].map((item) doSomething(item)));map 返回一个 Promise 数组Promise.all 负责让它们同时执行并等待全部完成。这个方法适合每个元素之间没有关联、且一次性并发量可控的场景。如果数组特别大一次性并发太多会导致资源耗尽就需要分批限流。分批限流的具体思路后面在排查技巧那一节会继续展开。3.5 项目里的 async/await 规范几个值得养成的习惯代码规范看起来琐碎但真的能救你一把。我的团队里慢慢沉淀起来的几条规则都是踩过坑才立的第一条不要在 async 函数外面直接调用 async 函数却不处理返回的 Promise。如果你调用了它但又没 await 也没 .catch一旦它内部 reject就会产生一个 unhandledrejection。很多时候项目里的全局报错都是这么漏出来的。第二条优先使用 eslint 的 no-floating-promises 和 require-await 规则。前一个强制你“处理每个 Promise”后一个提醒你别写一大堆没有 await 的 async 空壳函数。这两条规则能拦住相当一部分初级失误。第三条命名要体现异步性。函数名里带上 Async 后缀比如 loadUserAsync、saveOrderAsync看代码的人一眼就知道这个函数是异步的调用时要注意 await。这一点在大型协作项目里价值很高因为很多 bug 根本原因是“忘了加 await”。4. 常见问题与排查技巧实录这一节是我从真实的调试现场整理出来的。很多问题看起来玄学但根因其实都挺朴实而且相当一部分是同一个模式。4.1 永远 pending回调忘调、await 错位与死锁定位“为什么这个 promise 永远不 resolve”几乎每个写过异步代码的人都会问过这句话。最常见的两种原因第一种是把一个“不会 resolve”的 Promise 交给 await。比如某个库的初始化方法必须在特定事件触发后才执行回调但那个事件因为前面的某个异常被吞掉了永远不会触发于是挂住了。这种情况在接第三方 SDK 的时候特别常见。第二种是在 async 函数里 await 了一个“自锁”的 Promise。比如你在某段代码里先 setTimeout 然后期待用 await 等它结果定时器被写进了执行不到的分支或者回调里忘了调用 resolve。定位这类问题我的建议是先在 await 前后打日志确认执行是否真的到达了那个分支然后把可能挂住的部分加上超时兜底用前面提过的 withTimeout 把“永远 pending”变成“可感知的超时错误”。经历了几次这个排查过程之后你会慢慢养成一个习惯任何 await 都默认它可能挂住不预先信任它。4.2 执行顺序误区同步代码与 await 的隐藏边界有一次一个小伙伴跑过来问我为什么 async 函数里 await 后面的代码有时候会比外面同步代码先执行我们实际打印了一圈之后发现问题出在他把同步代码写进了 async 函数内部、且没有放在 await 前面。这种情况下的执行顺序其实非常有规律先执行 async 函数里第一个 await 之前的同步代码然后执行调用方后续的同步代码最后才轮到 await 之后的代码。这完全符合事件循环的规则不是什么玄学。如果你发现输出顺序和预期不符先检查一下你的“同步代码”到底写在了哪个函数的哪个位置。很多时候不是异步乱了是你对代码执行位置的直觉错了。我把这类问题整理成一个速查表方便你以后对照排查现象可能原因快速定位方法Promise 永远 pendingawait 了一个不会 resolve 的 Promise在 await 前后打日志另加超时兜底执行顺序不符合预期同步代码写在 async 函数内部或位置判断错误打印日志确认每个 console 所在的函数与位置Promise.all 一个失败全部失败没有区分 all 与 allSettled按业务需求改用 Promise.allSettled并发请求导致接口压力过大一次性发起大量 Promise分批限流每批执行完再执行下一批忘记 await调用 async 函数但没接返回值打开 no-floating-promises 规则检查4.3 三个调试心法断点、日志与慢请求排查调试 async/await 代码和调试普通同步代码最大的区别在于断点经常“跳来跳去”因为函数执行会被挂起和恢复。我自己的三条经验第一善用带条件的日志。在关键 await 之前打印带标识的日志比如[用户模块] 开始加载在 await 之后打印[用户模块] 加载完成耗时 xx ms。这套日志在生产环境里是救命稻草比你在本地调试器里单步调试有用得多。日志粒度要适中太细了刷屏太粗了定位不到问题。第二不要只猜网络慢。如果某个流程整体耗时长先打点找出耗时的具体环节再针对那个环节做优化。很多时候瓶颈是一个不起眼的 for 循环里悄悄放了一个 await导致本来可以并行的操作全变成了串行。这种事用肉眼很难看出问题但是打点之后一清二楚。第三合理利用“Promise.allSettled 分批”排查并发问题。数组特别大、并发量又高的时候直接 Promise.all 可能把下游接口打崩。可以把数组切成每批 10 个一批批地用 Promise.allSettled既能控制并发量又不会让某个失败影响整批结果。这其实是“限流”最简单的一种实现方式分批。如果需要更精确的限流还可以用信号量或跑一个简单的任务池但分批已经能解决 90% 的问题。4.4 一次典型的慢接口排查复盘讲一个典型的“抽象经验”。之前某个项目线上反馈说查询页面很慢打开要好几秒。查日志发现单个接口响应都在 100ms 以内说明不是后端问题。后来在关键路径上加时间戳结果发现前端在循环里做了一个很隐蔽的串行操作一个包含很多条数据的数组每条数据需要请求一次详情接口代码用的是 for...of 加 await相当于要等几十个请求依次完成。这里的问题不是 for...of 错了而是“每条数据都独立请求详情”这个设计本身就是性能灾难。后来做了两个优化第一个是把“详情接口”改成批量查询一次传一批 ID第二个是如果没法改后端就在前端做并发限制比如每批 5 个并发而不是完全串行。改完之后页面从几秒降到了 500ms 以内。这个案例给我的教训是遇到慢先看是不是异步并发设计出了问题再谈别的优化手段。5. 写在最后的个人体会最后说一点我自己真实的感觉。第一次用上 async/await 的时候明显觉得代码一下子“安静”了下来不再有层层叠叠的 .then不再有为了处理错误而刻意绕开的逻辑。它是我见过的最接近“让人以同步方式思考异步问题”的方案。但我也要泼一点冷水async/await 并不会自动让你的代码变得高效。如果你对它背后的执行机制了解不深反而可能写出比 Promise 链更慢、更隐蔽的 bug。所以我希望你在用这个特性的时候除了享受写法上的清爽一定要抽点时间把事件循环、微任务、Promise 的 settle 机制理清楚。这些知识才是你在复杂异步场景里真正游刃有余的底气。如果让我给一个最简单的成长建议那就是把自己手头项目里所有能改写的 Promise 链都改写成 async/await然后逐个场景对照执行顺序、错误处理、并发效果。改完一圈之后你对现代异步编程的理解绝对会再上一个台阶。