深入理解 async/await：从事件循环到并发控制与错误处理

差不多两个月前，我接手了一个内部工具的前端维护。用户反馈很一致：批量上传文件时，时不时就会冒出来一个“网络请求错误”，刷新一下又好了，但下次传多了还会再犯。打开控制台，满屏都是 (async upload fail error: 网络请求错误)，看得人头大。排查了一圈之后发现，问题全出在 async/await 上——有的地方并发没限流，有的错误被 Promise 悄悄吞掉，还有的地方压根没搞懂 await 在等什么。

后来我把这套排查过程整理成了下面这些内容，把 async/await 的本质、跨语言的表现、那个让不少人头疼的“传染性”、以及实际项目里的错误处理和并发控制，一次性讲清楚。JS、C#、Rust 都在范围内，因为这三个语言里的 async/await 表面长得像，底层完全是三个世界。无论你前端后端，只要写过异步代码，这篇应该都有点用。

1. 先把 async/await 的本质说透：它不是魔法，而是有代价的语法糖

1.1 从回调地狱到 async/await：演进背后的真正动机

早年写 JavaScript 异步，就是回调嵌套回调。文件读取成功后查数据库，查完再返回响应，三层嵌套之后代码就开始往屏幕右边飞，加上错误处理，每个回调里都要写 if (err)，维护成本直接起飞。Promise 解决了这个问题的“链式表达”，让嵌套变成了 .then() 的平铺，但业务复杂时，一堆 .then() 连在一起，读起来依然费劲。

async/await 出现之后，语法变化是决定性的：你可以用一种感官上完全同步的方式去写异步逻辑。但这个感官是非常容易骗人的——它只是把 Promise 的“链式回调”改写成了看起来顺序执行的样子，底层依然是回调那一套。你在 await 后面写的每一行代码，引擎都会把它编译成“在上一个 Promise resolve 之后执行的回调”，本质上还是回调函数，只是语言帮你把这些细节全部藏掉了。

我用餐厅的场景类比过很多次：你去餐厅点菜，把菜单递给服务员（发起异步请求），服务员不会一直站在你桌边等后厨做完，而是先去做别的事。菜做好了，服务员再端着菜回来找你（异步结果返回，继续执行后续代码）。餐厅并没有因此变快，出菜速度也没变，只是等待的过程里，服务员和厨房都没闲着。

这个类比里最关键的一点是：async/await 本身并不能让计算变快，也不能让网络请求变快，它的作用是让“等待结果”这个过程不再阻塞当前线程。CPU 密集型任务用 async/await 是解决不了性能问题的，这是很多人对 async/await 的第一个误解。

1.2 单线程的假并发：事件循环和微任务队列才是真正的主角

JavaScript 是单线程语言，但实际开发里，我们经常会看到一个 async 函数同时“发出”好几个网络请求，回来顺序还各不相同。很多人觉得这不可思议：单线程怎么会有并发？

答案是，网络 I/O 并不在线程上等待。浏览器和 Node 在发起网络请求时，底层走的是操作系统的异步事件通知机制。JavaScript 线程把请求丢出去之后，事件循环继续跑其他的任务。等某个请求的数据到达了，操作系统会通知事件循环，再把对应的回调排进任务队列里。

await 就是在这个“数据到达”的瞬间插入的逻辑。Promise resolve 之后，await 后面的代码不会立刻执行，而是被放到微任务队列里。当前宏任务结束后，微任务队列里的任务才会依次执行。这个顺序问题，在排查一些“看起来代码是对的但输出顺序不对”的 bug 时特别有用。

javascript复制async function test() {
  console.log('A');
  await Promise.resolve();
  console.log('B');
}

console.log('C');
test();
console.log('D');

上面这段代码的输出顺序是：C、A、D、B。很多人第一次看到会惊讶：为什么 B 排在 D 后面？因为 await 后面的代码被放进了微任务队列，宏任务 console.log('D') 会先执行完，微任务才轮到。不把“await 之后是微任务”这件事理解透，很多异步问题的排查就会绕远路。

这里补充一个小知识：微任务队列在浏览器和 Node 里都优先于下一个宏任务执行。setTimeout(0) 这种写法排的是宏任务队列，所以如果你想“看看当前微任务跑完了没有”，用 setTimeout 是看不到的，它反而排在微任务后面。

2. 三套外衣：JavaScript、C#、Rust 的 async/await 到底哪里不一样

2.1 JavaScript：顺手，但每一步都在事件循环里

JavaScript 的 async 函数在调用时，会立刻返回一个 Promise 对象。哪怕你在这个函数里返回的是一个简单字符串，调用方拿到的也是一个 Promise，不是字符串本身。这个细节看着低级，实际项目里真有人踩过：

javascript复制async function getData() {
  return { name: 'test' };
}

const result = getData(); // 这里拿到的是 Promise，不是 { name: 'test' }
console.log(result.name); // undefined

更麻烦的其实是错误处理。一个 async 函数内部抛出异常，Promise 的状态会变成 rejected。如果调用方没有及时处理，就会触发 unhandledrejection。这类错误的一个特点是：它可能不会立刻让你看到影响，但它在后台悬着，哪天外部环境一变，它就冒出来了。

还有一个容易踩的坑是 forEach 循环。很多人这样写：

javascript复制files.forEach(async (file) => {
  await uploadFile(file);
});

这个写法是错误的。forEach 不会等待 Promise resolve，它只是把 async (file) => {...} 这个函数逐个调用一遍就结束了。所有上传请求其实同时发出去了，后面的并发问题就是这么来的。要一个一个等，得用 for...of。

2.2 C#：编译器状态机，以及“线程被释放”带来的新问题

C# 的 async/await 从底层上看，和 JavaScript 完全不同。C# 的编译器会把 async 方法拆成一个状态机，方法执行到 await 时，如果 Task 还没完成，当前线程会从线程池里归还回去。等到 Task 完成，再由线程池调一个线程来继续执行剩余代码。这个过程使得线程池的利用率大幅提高。

所以，C# 里 async/await 的核心价值之一是“释放线程”，而不是“新建线程”。很多老项目里，大家习惯用 Task.Run 去“开一个线程”，但对于网络请求、文件读取这类 I/O 操作，真正合理的做法是直接 await 原生异步 API，而不是绕一层线程池。

C# 里最值得警惕的是 async void。async Task 方法里的异常可以被 await 捕获，但 async void 方法的异常会直接抛到当前同步上下文，绕过了外层所有 try/catch。UI 事件处理器经常被迫使用 async void，一旦内部抛错，整个进程可能直接崩掉。如果不得不写 async void，函数体内必须自己包一层 try/catch，不能让异常裸奔。

另一个 C# 老坑是死锁。在 UI 线程上，如果你在同步代码里调用 .Result 或者 .Wait() 去等待一个异步任务，而那个异步任务后续需要回到 UI 线程继续执行，就会互相等死。ConfigureAwait(false) 能在库代码里缓解这个问题，但在 UI 层随便用又可能丢掉上下文，需要结合场景仔细权衡。

2.3 Rust：没有内置运行时，async 是一张“惰性”蓝图

Rust 的 async/await 是另一条路线。Rust 标准库不提供异步运行时，async 关键字只是把一个代码块转换成一个实现了 Future trait 的结构体。这个 Future 跟 JavaScript 的 Promise 最大的区别是：它不执行，除非有执行器去轮询它。

所谓“惰性”，我举个例子。在 JavaScript 里，你调用一个 async 函数，函数体至少会执行到你写第一个 await 的地方。但在 Rust 里，你创建了一个 async block 或 async fn，仅仅是把一个 Future 创建出来了，里面的代码一步都没跑。你必须把它交给 tokio 这类执行器去 poll，它才会真正推进。很多 Rust 新手第一次踩的坑就是：创建了异步任务，没 spawn，结果什么输出都没有，代码也不报错，好像根本没执行过一样。

Rust 异步还有一个更让人头疼的点：借用检查。async block 会把捕获的变量一起存进 Future 结构体里。如果这些变量是借用来的，Future 活得比借用源更长，编译器立刻报错。实际代码里常用的解法是 async move 配合所有权转移，或者在多个任务间共享数据时使用 Arc。和 JavaScript 的“自由”相比，Rust 是在编译期间强制你处理异步值的生命周期，前期痛苦，后期稳定。

3. async 的“传染性”不是 bug，是设计在提醒你异步边界

3.1 传染是什么意思？为什么代码写起来“停不下来”

如果你写过这样的代码，多半能立刻理解什么叫传染性：

javascript复制function getUserSync() {
  return getUserAsync(); // 返回的是 Promise，不是 user
}

一个同步函数里调用 async 函数，返回的是一个 Promise，而不是你期望的数据。于是调用方只能继续把它当作 Promise 处理：要么 await，要么 .then()，要么再把 Promise 往上层传。上层如果也是同步函数，它的返回值也就被迫变成了 Promise。就这么一层一层往上传染，直到某个层级愿意把整个方法签名改成 async。

这种传染让很多人觉得 async/await 侵入性太强。老项目里特别明显：一个底层的数据库查询改成了 async，整个调用链的几十个函数都要跟着改签名，大量 diff，大量潜在出错点。

但从语言设计角度讲，这个传染是故意的。异步结果本质上就是“未来某个时刻才有的值”，你没有办法把一个未来才有的东西塞进当前时刻的同步流程里。async/await 的传染性相当于在每个调用点加了一个显式标记：你正在接触一个异步值，请做好准备。这个标记让“同步代码里意外用到异步结果”的错误能尽早暴露，而不是等到线上某个请求里拿到 undefined 才查得头昏脑涨。

3.2 为什么这个“故意设计”依然让人难受

传染性的最大敌人，是历史包袱。我接手过的很多业务系统里，底层工具函数全是同步返回，中间业务层大部分也是同步方法。偶尔一次底层驱动升级，把同步 API 改成了异步，上层所有依赖它的函数必须跟着改。遇到老旧的、没有测试覆盖的代码，这种改动的风险是几何级上升的。

另一个尴尬场景是，第三方库根本没有 async-ready。有些老牌的 ORM、缓存客户端只提供同步 API。为了统一调用链，你被迫在自己的 async 函数里用某种“同步等待”的变通手段，比如把 Task 的 GetAwaiter().GetResult() 拉出来用。这个手段在控制台程序里也许没问题，但在真正的高并发、线程池环境里，会引入额外的死锁和线程饥饿风险。

还有一类隐性风险来自那些“半成品”异步库。它们提供了 async 接口，但内部对异常处理是敷衍的，该 reject 的不 reject，该 catch 的不 catch。流量小的时候平稳运行，流量一上来，突然浮出一片 unhandledrejection，到那时候你再去逐层查哪个 Promise 没有被处理，非常痛苦。

3.3 实操里怎么止住传染

先明确一点：完全“止住”传染是不可能的，也是不合理的。异步值就是异步值，语言设计不允许你假装它是同步的。实际项目里能做的，是把传染面控制在合理的范围内。

现在的操作习惯里，我用得最多的是“异步边界”思想。具体来说：

1. 给每个业务模块划一条清晰的异步边界。接口层、路由层、服务入口层可以是 async，内部的小工具函数尽量保持同步，不随便引入异步依赖。这样传染面就不会蔓延到整个项目。
2. 异步到底，但要有规划。不要在中间层拿到 Promise 后又偷偷转成同步，那样既丢失了并发的优势，又增加了维护成本。不如让异步沿着调用链一直传到边界。
3. 对于老代码兼容，用适配器模式包一层。同步接口对外，内部实现里做一个同步等待。这个方案要写清楚注释，明确这个同步包装只能在启动阶段或独立线程里使用，不能在高并发请求路径上滥用。
4. 在 JavaScript 里，尽可能把“需要等待的异步数据”控制在模块入口处 await，拿到干净的数据模型再往下传。下游全是同步函数，传染面就非常小。

边界划分这事，和系统架构里的服务拆分很像。你不可能让所有服务都互相直连，中间总要有个网关或者消息队列来承接异步交互。代码里的 async 边界，就是这个网关。

4. 从一次真实上传事故聊起：async/await 的错误处理与并发控制

4.1 复现并发上传导致的“网络请求错误”

回到开头说的那个项目。初期实现很简单，一个 for 循环，每个文件逐一上传：

javascript复制for (const file of files) {
  await uploadFile(file);
}

功能能跑，但性能极低。用户一次传二三十个文件，全部串行排队，最慢的一个卡住，后面全部跟着等。内部工具使用者抱怨很多，于是改成“并行”：

javascript复制await Promise.all(files.map((file) => uploadFile(file)));

一改就翻车了。二三十个文件同一时间发出，浏览器和服务器之间的连接数是有限制的，大量请求被挂起，部分直接超时失败。控制台开始冒出一堆 (async upload fail error: 网络请求错误)。

这个事故背后有两点值得说透。第一，async/await 本身是不产生并发的，并发是你主动发出的请求数。第二，Promise.all 并不是“并发控制工具”，它是“等所有 Promise 完成的聚合器”，它根本不管同时跑几个，只负责把所有结果汇总回来。并发控制需要你自己来做。

4.2 上传失败的三类原因和排查位置

真实业务里，网络上传失败的原因通常可以归成三类：

排查“网络请求错误”这种通用错误信息时，第一步永远不是改代码，而是先看接口返回状态和真实响应内容。这个报错往往是前端对异常信息的二次包装，把原始错误细节吞掉了。我后来在这个项目里给 upload 函数加了一段 logger，捕获错误时把 error.name、error.message、error.cause 以及请求 url 全部记录下来，很多“灵异现象”在看到日志的瞬间就明白了。

尤其要注意，async 函数里 catch 网络错误时，千万别把原始错误对象丢掉。很多人习惯这样：

javascript复制async function upload(file) {
  try {
    await fetch('/upload', { body: file });
  } catch (e) {
    throw new Error('上传失败'); // 原始错误信息全丢了
  }
}

这样抛出来的错误，日志里只能看到“上传失败”四个字，原始的状态码、失败原因全没了。后面排查问题，等于盲人摸象。正确做法是把原始错误挂到新错误上：throw new Error('上传失败', { cause: e })，这样既能保留业务语义，又不丢失技术细节。

4.3 真正的并发控制：有上限的 Promise 调度

那次事故的最终解法，是给上传加了一个带并发上限的调度器。核心逻辑其实很简单：维护一个“正在执行”的任务集合，如果正在执行的数量达到了上限，就等其中一个完成，再放新的任务进来。以下是一个极简版本：

javascript复制async function runWithLimit(tasks, limit) {
  const executing = new Set();
  for (const task of tasks) {
    const p = Promise.resolve().then(() => task());
    executing.add(p);
    const clean = () => executing.delete(p);
    p.then(clean, clean);
    if (executing.size >= limit) {
      await Promise.race(executing);
    }
  }
  await Promise.all(executing);
}

await runWithLimit(files.map((f) => () => uploadFile(f)), 3);

这个写法的本质是一个信号量。每次往执行集合里放一个任务，如果数量到了上限，就用 Promise.race 等待其中一个先完成，腾出位置继续放。注意 tasks 里的每个项目必须包一层函数，否则任务在进入调度器之前就已经开始执行了，调度器失去控制权。

实际生产环境里，我建议直接使用 p-limit 这类经过大量验证的库，不必每次都手写。但手写一遍的目的在于理解原理——缓存数据库连接、批量消息发送、图片压缩、文件上传，全都适用这个“有上限的并发”模型。

还有一个细节必须提：上传文件时不能只依赖浏览器默认超时。很多场景下要自己设一个时间限制，用 AbortController 把超时取消和请求生命周期绑定起来是推荐做法：

javascript复制async function uploadWithTimeout(file, timeoutMs = 30000) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);
  try {
    return await fetch('/upload', {
      method: 'POST',
      body: file,
      signal: controller.signal,
    });
  } finally {
    clearTimeout(timer);
  }
}

还有一点经常被忽视：并发请求时，如果一个请求失败，其他请求会怎样？Promise.all 是有一个失败就整体失败，Promise.any 是第一个成功就返回成功，Promise.race 是等第一个完成（无论成功失败），allSettled 是等所有完成并把每个结果都返回给你。选错聚合函数，行为差异极大。在处理批量上传这种场景，我更喜欢 allSettled，这样可以单独列出失败的文件，而不是因为一个文件失败就把整个批次标记为失败。

5. 这些年写 async/await，我保留的几个习惯

关于 async/await 的文章，大部分会停留在语法介绍层面。但我更想说的是，真正让异步代码变得可控的，是你愿不愿意面对那几个不太舒服的事实：异步会传染、并发要限流、异常必须有人接住。围绕这三点，我慢慢养成了几个写代码的固定习惯。

第一，写任何 async 函数之前，先想清楚“这里要不要吞错误”。业务层可以 catch 后转换成业务错误，但底层封装的异步函数，我基本不 catch，让异常向上传播，交给统一错误处理。这样日志里能保留完整的原始错误链，排查问题极其有帮助。

第二，每个可能长时间等待的 await，我都会问一遍自己：如果它永远不回来，会怎样？分布式环境下没有“永远不会失败”的网络请求，只有超时时间设得够不够短。给 await 包一层超时，或者用 AbortController，现在已经是我的默认动作，而不是事后补救。

第三，async 函数里尽量避免出现“裸的 Promise”。什么是裸 Promise？就是没有用 await 等待，也没有立即 catch 的 Promise。它被丢在那里自生自灭。比如把 async 函数直接丢给某个事件订阅器，却不关心它内部的异常。这种代码在低流量时安然无恙，流量一起来就是一堆幽灵报错。

第四，代码评审时只要看到 async void，我一定要求改掉。异步方法必须被 await 或者被统一的任务容器管理，裸露的 void 上下文承担不起异常处理的重量。

最后聊个调试技巧。排查 async 相关的疑难杂症，我最先做的不是看源码，而是把出错的调用链打出来。JavaScript 里可以用 async_hooks 把异步上下文的创建关系串联起来，C# 里可以用 AsyncLocal，Rust 里用 tracing 可以做异步任务日志追踪。这些工具可能不是日常必备，但遇到那种“看似随机失败”的邪门问题时，它们能帮你从噪声里找到规律。大多数 async 相关的线上事故，追到最后都是同一个原因：某个异步任务的失败被安放在了错误的位置，或者并发控制出了问题。

写 async/await 写多了会发现，语言特性只是表面。真正考验的，是你有没有想清楚异步边界在哪、并发上限设多少、异常归谁管。这三件事想明白了，不管是 JavaScript、C# 还是 Rust，写异步代码都不容易翻车。