async/await底层原理与7个高阶实战用法

1. 这不是语法糖，是 JavaScript 异步编程的“操作系统层”重构

你写过async function fetchUser() { const res = await fetch('/api/user'); return res.json(); }—— 这行代码背后，不是简单的“等一等再往下走”，而是一整套运行时调度机制在 silently 重排你的代码执行流。我做前端架构和大型应用性能优化十年，从 jQuery 回调地狱一路踩坑到现代 React/Vue 3 的 Suspense 边界，越来越确信：async/await不是Promise.then()的语法糖，它是 JavaScript 引擎为开发者提供的第一层异步抽象接口，其设计深度直抵事件循环（Event Loop）内核。它解决的从来不是“怎么写更短”，而是“怎么让并发逻辑可预测、可调试、可中断、可组合”。标题里说的“7个高级用法”，本质是7个对这个底层调度模型的精准操控切口——比如await Promise.race([timeout, apiCall])不是炫技，而是用 Promise 状态机强行给异步操作装上“超时熔断阀”；await (async () => { /* do work */ })()也不是多此一举，而是利用 async 函数立即执行特性，在不污染外层作用域的前提下创建一个带 await 能力的独立执行上下文。这些用法之所以“高级”，是因为它们绕开了语言表面语法，直接与 V8 的 microtask 队列、任务队列（task queue）和 PromiseResolveThenableJob 的调度规则打交道。如果你还在用setTimeout(() => { /* 模拟异步 */ }, 0)来“让出线程”，那你还没真正理解await的底层契约：它触发的是 microtask 插入，而非 task 延迟，这意味着它的执行优先级高于setTimeout和setInterval，但低于同步代码。这微小的优先级差，就是你在处理表单提交防重复点击、动画帧同步、或 WebSocket 心跳保活时成败的关键。所以这篇内容，面向的不是刚学fetch的新手，而是已经能写出useEffect依赖数组、能看懂Promise.allSettled返回结构、但在复杂业务场景中仍会遇到“为什么 await 后的代码没按预期顺序执行”“为什么 catch 没捕获到错误”“为什么 finally 里的清理逻辑总被跳过”的中级到高级开发者。它不教你怎么写第一个async函数，而是告诉你：当你的电商秒杀页要同时发起库存查询、用户权限校验、优惠券匹配三个 API，且要求任意一个失败就终止后续、所有请求必须 800ms 内响应、失败时需精确上报是哪个环节超时——这时候，那7个用法，就是你手里的手术刀。

2. 核心设计逻辑：从状态机视角解构 async/await 的真实工作流

2.1 async 函数的本质：一个自动生成的 Promise 工厂 + 状态控制器

很多人误以为async function foo() { return 42; }等价于function foo() { return Promise.resolve(42); }。这是危险的简化。实际编译过程远比这复杂。V8 引擎在解析async函数时，会做三件事：

1. 自动包裹 Promise 构造器：将函数体整体包裹进new Promise((resolve, reject) => { ... })；
2. 注入状态跟踪器：为每个await表达式生成一个隐式的Promise.then()链，并在内部维护一个state变量（如pending/fulfilled/rejected），该变量不暴露给开发者，但决定await后续代码是否执行；
3. 重写 return 语义：return value不再是函数返回值，而是触发resolve(value)；throw err触发reject(err)；甚至return Promise.reject(err)也会被二次包装，确保最终 Promise 状态唯一。

你可以用 Babel 的@babel/plugin-transform-async-to-generator插件反编译验证：async function test() { await delay(1000); return 'done'; }会被转成一个generator function*，其内部yield对应await，next()调用对应 microtask 执行。这解释了为什么async函数无法被try...catch完全覆盖——因为await后的代码实际运行在另一个 microtask 中，try块的栈帧早已弹出。这也是await无法捕获setTimeout抛出错误的根本原因：setTimeout是 macro-task，其回调在下一个 Event Loop Tick 才执行，而try的作用域早已失效。

提示：async函数返回的 Promise，其[[PromiseState]]属性（可通过Object.getOwnPropertyNames(promise)查看）在await执行前是"pending"，await解析后变为"fulfilled"或"rejected"。这个状态变化是引擎内部触发的，不可手动修改，任何试图promise.state = 'fulfilled'的操作都会静默失败。

2.2 await 的底层契约：microtask 插入点，而非“暂停指令”

await最常被误解为“暂停当前函数执行”。错。它的真实行为是：将await表达式右侧的 Promise（或 thenable）的then回调，作为一个 microtask 插入当前 Event Loop 的 microtask 队列末尾，并立即返回控制权给调用者。这意味着：

• await之后的代码，不是“暂停后继续”，而是被注册为 microtask 的回调；
• 如果await右侧是一个已fulfilled的 Promise（如await Promise.resolve(1)），该 microtask 会立刻在当前 tick 的 microtask 阶段执行，看起来像“同步”；
• 如果右侧是pendingPromise（如await fetch(...)），则 microtask 会等待 Promise 状态变更后再执行；
• 关键点：await本身不阻塞 JS 主线程，它只是调度器的一个指令。

这个认知差异直接导致实操陷阱。例如：

console.log('A'); await Promise.resolve(); console.log('B');

输出是A→B，看似同步。但若换成：

console.log('A'); await new Promise(resolve => setTimeout(resolve, 0)); console.log('B');

输出仍是A→B，但B的打印发生在下一个 Event Loop Tick 的 microtask 阶段，而非当前 tick。很多开发者因此误判“await很快”，在性能敏感场景（如 Canvas 动画帧内）滥用await，结果发现帧率暴跌——因为每个await都强制插入一个 microtask，而 microtask 队列在每次 tick 结束时必须清空，大量 microtask 会挤压后续渲染任务。

2.3 为什么需要“高级用法”？—— 基础语法无法覆盖的真实战场

基础async/await在简单 CRUD 场景下足够，但一旦进入以下领域，就会暴露能力边界：

• 竞态条件（Race Conditions）：用户快速连续点击“提交”按钮，多个await fetch()并发发出，如何确保只处理最后一次响应？Promise.race()可以，但race本身不取消已发出的请求，网络层仍在传输。
• 资源泄漏：await一个长时 WebSocket 连接，用户在等待期间关闭页面，await的 microtask 仍会执行，尝试操作已销毁的 DOM 元素，报Cannot read property 'appendChild' of null。
• 错误传播失真：await Promise.all([p1, p2, p3])中任一 Promise 失败，整个all被 reject，但你丢失了其他两个 Promise 的状态信息，无法知道是p1超时还是p2网络错误。
• 执行流不可控：await后的代码无法被外部中断，没有类似AbortController对await本身的控制能力。

这7个高级用法，每一个都是针对上述某类战场问题的精准回应。它们不是炫技清单，而是工程师在真实项目中，用血泪换来的“防御性编程”工具箱。

3. 7个核心高级用法详解：原理、场景、代码与避坑指南

3.1 用 Promise.race 实现带超时的 await（Timeout Control）

原理：Promise.race()返回第一个 settled（fulfilled 或 rejected）的 Promise。将其与目标 Promise 组合，即可实现“超时熔断”。

标准写法：

function timeout(ms, promise) { const controller = new AbortController(); const timeoutPromise = new Promise((_, reject) => { setTimeout(() => { controller.abort(); reject(new Error(`Timeout after ${ms}ms`)); }, ms); }); // 注意：这里必须使用 signal，否则 fetch 不会真正取消 return Promise.race([ promise, timeoutPromise ]); } // 使用 try { const data = await timeout(5000, fetch('/api/data', { signal: controller.signal })); const result = await data.json(); } catch (err) { if (err.name === 'AbortError') { console.log('请求被超时取消'); } else { console.error('网络错误:', err); } }

为什么不能只用Promise.race([fetch(), new Promise(...)])？
因为fetch()本身不响应AbortSignal，除非显式传入signal选项。否则timeoutPromisereject 后，fetch请求仍在后台运行，浪费带宽和服务器资源。AbortController是浏览器原生支持的取消机制，fetch、XMLHttpRequest、setTimeout（通过clearTimeout）都支持它。

实操心得：我在一个金融行情系统中，所有实时数据请求都强制加 3s 超时。但发现Promise.race有个隐藏陷阱：如果fetch在timeoutPromisereject 前已 resolve，race返回fetch的 Promise；但如果fetchresolve 后，timeoutPromise的setTimeout仍会执行并reject，此时若未正确处理AbortController，可能触发未捕获的 Promise rejection（Uncaught Promise Rejection）。解决方案是在timeoutPromise的setTimeout回调中，先检查controller.signal.aborted，再决定是否reject。

3.2 用 IIFE 创建独立 await 上下文（Isolated Await Context）

原理：async函数会自动返回 Promise，而立即执行的 async 函数（IIFE）可以创建一个不污染外层作用域、且自带await能力的封闭执行环境。

标准写法：

// 场景：在一个非 async 的事件处理器中，需要 await 某个操作，但又不想把整个函数改成 async（因为 async 会改变返回值类型） button.addEventListener('click', () => { (async () => { try { const data = await fetchData(); updateUI(data); } catch (err) { showError(err); } })(); }); // 更高级用法：动态生成 await 链 const createAsyncPipeline = (...fns) => async (input) => { let result = input; for (const fn of fns) { result = await fn(result); } return result; }; const pipeline = createAsyncPipeline( async (x) => x * 2, async (x) => x + 1, async (x) => x.toString() ); pipeline(5).then(console.log); // "11"

为什么需要它？
Vue 2 的methods选项中，事件处理器通常是普通函数。若改为async method() {}，其返回值是 Promise，而 Vue 的事件绑定@click="method"会忽略 Promise，导致await失效。IIFE 是最轻量的解决方案。另外，在 Node.js 的fs.readFile回调中，也常用此模式避免回调地狱。

避坑指南：IIFE 的async函数内部await的错误，不会冒泡到外层try...catch。例如：

try { (async () => { await Promise.reject('oops'); })(); } catch (e) { // 这里永远不会执行！ }

因为 IIFE 返回的是 Promise，错误在 Promise 内部被抛出，需用.catch()处理：

(async () => { await Promise.reject('oops'); })().catch(console.error);

3.3 用 Promise.allSettled 处理“尽力而为”的并发（Graceful Concurrent Execution）

原理：Promise.allSettled()不会因某个 Promise 失败而中断，它返回一个包含所有 Promise 结果（{ status: 'fulfilled' | 'rejected', value | reason }）的数组。

标准写法：

// 场景：加载用户头像、昵称、积分三个独立 API，允许部分失败 const [avatarRes, nameRes, pointsRes] = await Promise.allSettled([ fetch('/api/avatar'), fetch('/api/name'), fetch('/api/points') ]); const userData = {}; if (avatarRes.status === 'fulfilled') { userData.avatar = await avatarRes.value.json(); } if (nameRes.status === 'fulfilled') { userData.name = await nameRes.value.json(); } if (pointsRes.status === 'fulfilled') { userData.points = await pointsRes.value.json(); } renderProfile(userData);

对比Promise.all：all是“全有或全无”，适合强一致性场景（如转账，必须账户余额和交易记录同时更新成功）；allSettled是“尽力而为”，适合弱一致性场景（如用户资料页，头像加载失败不影响昵称显示）。

实操心得：allSettled的结果数组顺序严格对应输入 Promise 数组顺序，这点非常关键。我在一个仪表盘项目中，需要并行请求 12 个不同维度的数据，用allSettled后，通过results.map((r, i) => ({ id: ids[i], ...r }))就能完美关联每个结果和其原始 ID，无需额外映射逻辑。另外，allSettled的status字段是字符串，不是布尔值，务必用===严格比较，避免if (r.status)这种错误判断（'rejected'是真值）。

3.4 用 await + for...of 实现可控的串行迭代（Controlled Serial Iteration）

原理：for...of遍历async函数返回的 Promise，await会逐个等待每个 Promise settle，形成串行执行流。

标准写法：

// 场景：批量上传文件，要求按顺序上传，且每个文件上传成功后才开始下一个 async function uploadFilesSequentially(files) { const results = []; for (const file of files) { try { const result = await uploadFile(file); // 等待单个文件上传完成 results.push({ file: file.name, status: 'success', data: result }); } catch (err) { results.push({ file: file.name, status: 'error', error: err.message }); // 可选择 continue（跳过失败文件）或 break（停止整个流程） continue; } } return results; } // 更高级：带进度回调的串行 async function uploadWithProgress(files, onProgress) { for (let i = 0; i < files.length; i++) { await uploadFile(files[i]); onProgress((i + 1) / files.length); // 通知进度 } }

为什么不用files.map(uploadFile).forEach(...)？
map会立即发起所有请求，形成并发，失去“串行”控制。forEach无法await其回调函数内的 Promise，导致执行顺序混乱。

避坑指南：for...of的await是逐个等待，但for (let i = 0; i < arr.length; i++)中的await同样有效。选择for...of是为了语义清晰和自动处理Symbol.iterator。另外，for...of在遍历过程中，若数组被修改（如push新元素），新元素会被遍历到，这是与传统for循环的重要区别。

3.5 用 await + try...finally 实现可靠的资源清理（Guaranteed Cleanup）

原理：finally块无论try中是否await、是否抛出错误，都会执行，是放置清理逻辑的黄金位置。

标准写法：

// 场景：打开一个 WebSocket 连接，进行数据交互，确保连接一定关闭 async function chatWithUser(userId) { const socket = new WebSocket(`wss://chat.example.com/${userId}`); try { // 等待连接建立 await new Promise((resolve, reject) => { socket.onopen = resolve; socket.onerror = reject; }); // 发送消息并等待响应 socket.send(JSON.stringify({ type: 'hello' })); const response = await new Promise((resolve) => { socket.onmessage = (e) => resolve(JSON.parse(e.data)); }); return response; } finally { // 关键：这里一定会执行！ if (socket.readyState === WebSocket.OPEN || socket.readyState === WebSocket.CONNECTING) { socket.close(); } } }

为什么finally比catch更可靠？
catch只捕获try块内的错误，但await后的 Promise rejection 若未被catch，会变成 unhandled rejection。而finally不关心try是否成功，它只保证“无论发生什么，这段代码都要跑”。我在一个视频编辑 Web 应用中，用finally确保MediaRecorder停止并释放BlobURL，避免内存泄漏——即使用户在录制中途刷新页面，finally里的URL.revokeObjectURL()仍会执行。

注意：finally中的await是允许的，但需谨慎。例如await socket.close()是异步的，finally会等待它完成。但若finally中的await也抛错，该错误会覆盖try中的原始错误，导致调试困难。因此，finally中的异步操作应尽量用catch包裹。

3.6 用 await + Promise.resolve().then() 实现微任务调度（Microtask Scheduling）

原理：Promise.resolve().then()显式创建一个 microtask，await它可将后续代码推入下一个 microtask 阶段，实现“让出当前 tick”的效果。

标准写法：

// 场景：在 Vue 的 nextTick 或 React 的 flushSync 后，确保 DOM 更新完成再执行 async function updateAndScroll() { // 更新状态 this.items = [...this.items, newItem]; // 等待 Vue 的 nextTick（或 React 的 flushSync）完成 await Promise.resolve(); // 此时 DOM 已更新，可安全操作 this.$nextTick(() => { this.$refs.list.scrollTop = this.$refs.list.scrollHeight; }); } // 更通用：创建一个 waitNextTick 函数 const waitNextTick = () => Promise.resolve(); // 使用 await waitNextTick(); // DOM 更新后执行

为什么不用setTimeout(() => {}, 0)？
setTimeout是 macro-task，会在下一个 Event Loop Tick 执行，而Promise.resolve().then()是 micro-task，会在当前 tick 的 microtask 阶段执行，时机更早、更精确。在动画帧（requestAnimationFrame）内，await Promise.resolve()可以确保代码在rAF回调之后、渲染之前执行，实现像素级控制。

实操心得：这个技巧在实现平滑滚动、Canvas 动画同步、或解决“DOM 未更新就操作”的 bug 时极其有效。但要注意，过度使用 microtask 会导致 microtask 队列过长，影响页面响应。我在一个高频数据可视化项目中，曾因在for循环中每轮都await Promise.resolve()，导致 100 次循环产生 100 个 microtask，严重拖慢主线程。后来改用if (i % 10 === 0) await Promise.resolve()进行节流，性能提升显著。

3.7 用 await + Generator Function 实现协程式状态管理（Coroutine-like State Management）

原理：Generator 函数（function*）配合async/await，可创建可暂停、可恢复的执行流，模拟协程（Coroutine）。

标准写法：

// 场景：一个复杂的表单向导，步骤间有异步校验，且需支持回退、跳转 function* formWizard() { yield 'step1'; // 第一步 const valid1 = yield validateStep1(); // 异步校验 if (!valid1) return 'error'; yield 'step2'; const valid2 = yield validateStep2(); if (!valid2) return 'error'; yield 'submit'; const result = yield submitForm(); return result; } // 协程驱动器 async function runWizard(wizard) { const gen = wizard(); let result = gen.next(); while (!result.done) { if (result.value instanceof Promise) { // 如果 yield 出来的是 Promise，await 它 const resolved = await result.value; result = gen.next(resolved); } else { // 否则直接 next result = gen.next(); } } return result.value; } // 使用 runWizard(formWizard).then(console.log);

为什么需要它？
当业务逻辑跨越多个异步步骤，且步骤间有复杂的状态依赖（如步骤2依赖步骤1的校验结果），传统的async/await链会变得冗长难维护。Generator 提供了显式的“暂停点”（yield），让状态流转一目了然。

避坑指南：Generator 的yield表达式本身不返回值，gen.next(value)的value参数会作为上一个yield表达式的返回值。因此，yield validateStep1()的返回值是validateStep1()的 Promise，gen.next(resolved)的resolved会成为validateStep1()的返回值，供后续逻辑使用。这是一个容易混淆的点，建议在yield后加注释说明预期返回值类型。

4. 实战避坑大全：那些只有踩过才懂的 async/await 坑

4.1 “await 之后的代码没执行” —— 未处理的 Promise rejection

现象：await fetch('/api/data')后的console.log('done')永远不打印。

根本原因：fetch失败时抛出TypeError，但未被try...catch捕获，导致 Promise rejection 未处理，JS 引擎静默丢弃后续 microtask。

排查步骤：

1. 检查浏览器控制台是否有Uncaught (in promise)错误；
2. 在await前后添加console.log，确认执行流卡在await；
3. 用fetch().catch(console.error)测试是否真的失败。

解决方案：

• 必须用try...catch包裹await；
• 或在async函数末尾加.catch()（不推荐，破坏链式）；
• 全局监听：window.addEventListener('unhandledrejection', event => { /* log */ });

注意：try...catch只捕获try块内await的 rejection，对await后的代码中抛出的错误无效。因此，await后的代码也应有防御性检查。

4.2 “await 了，但 DOM 没更新” —— 渲染时机与 microtask 顺序

现象：this.loading = true; await apiCall(); this.loading = false;，但 loading 状态在 UI 上一闪而过，用户几乎看不到。

根本原因：this.loading = true是同步操作，触发 Vue/React 的响应式更新，但 DOM 渲染发生在当前 tick 结束后的rAF阶段。而await apiCall()的 microtask 在rAF之前执行，this.loading = false立即覆盖了true状态，导致渲染时loading已为false。

解决方案：

• 使用框架提供的nextTick/flushSync：this.loading = true; await this.$nextTick(); await apiCall(); this.loading = false;
• 或await Promise.resolve()让出当前 tick：this.loading = true; await Promise.resolve(); await apiCall(); this.loading = false;
• 更佳实践：将 loading 状态与请求 Promise 绑定，用v-if="loadingPromise"直接控制显示。

4.3 “多个 await 导致性能暴跌” —— microtask 队列膨胀

现象：一个循环中for (let i=0; i<100; i++) { await someAsyncOp(i); }，执行时间远超预期。

根本原因：每个await都插入一个 microtask，100 个 microtask 会阻塞当前 tick 的 microtask 队列，挤压后续渲染和用户交互任务。

量化分析：假设每个someAsyncOp耗时 1ms，100 次串行await理论耗时 100ms。但实际中，microtask 队列处理开销叠加，可能达到 200ms+，且期间页面完全无响应。

优化方案：

• 批处理：将 100 个操作合并为一个Promise.all()并发请求；
• 节流：if (i % 10 === 0) await Promise.resolve();每 10 次插入一个 microtask 间隙；
• 降级为 macro-task：if (i % 10 === 0) await new Promise(r => setTimeout(r, 0));，牺牲一点精度换取流畅性。

4.4 “await 一个非 Promise 值” —— 隐式 Promise 包装的陷阱

现象：await 42返回42，await null返回null，看似正常，但可能导致逻辑错误。

根本原因：await会对非 Promise 值自动调用Promise.resolve(value)，这没问题。但问题在于，await总是返回一个 Promise，即使value是null，await null的返回值也是Promise {<fulfilled>: null}，其.then()回调接收null。

风险场景：

// 错误：认为 await obj.property 会返回 undefined，但实际是 Promise const user = await getUser(); const profile = await user?.profile; // 如果 user 为 null，user?.profile 是 undefined，await undefined 返回 Promise {<fulfilled>: undefined} // 正确：先检查，再 await if (user && user.profile) { const profile = await user.profile; }

最佳实践：永远假设await的右侧可能为null/undefined，并在await前做空值检查，或使用可选链await user?.profile?.fetch?.()（注意：可选链后的fetch()必须是函数，且返回 Promise）。

4.5 “async 函数的 this 绑定丢失” —— 箭头函数与普通函数的差异

现象：class Component { async handleClick() { console.log(this); } }，在button.onclick = instance.handleClick时，this为undefined。

根本原因：async函数本质是普通函数，this绑定遵循常规规则。箭头函数不绑定this，会继承外层作用域的this；普通async函数会丢失this。

解决方案：

• 使用箭头函数：handleClick = async () => { /* this 正确 */ };
• 在构造函数中绑定：this.handleClick = this.handleClick.bind(this);
• 使用事件委托，避免直接赋值函数。

提示：Vue 3 的<script setup>中，defineOptions和defineProps的setup函数是箭头函数，this不存在，因此async方法天然绑定正确。

5. 工具链与调试技巧：让 async/await 可见、可测、可追踪

5.1 Chrome DevTools 的 async 调试实战

Chrome 的 Sources 面板提供了强大的 async 调试能力：

• Async Call Stack：在断点处，勾选Async，调用栈会显示await的完整链路，包括Promise.then的 microtask 入口；
• Blackboxing：右键node_modules中的regenerator-runtime，选择Blackbox script，避免跳进 transpiler 生成的 generator 代码；
• Promise Inspector：在 Console 中，输入await Promise.resolve(1)，DevTools 会显示 Promise 的[[PromiseState]]和[[PromiseResult]]，直观验证状态。

实操技巧：在await行设置断点，按F10单步，会直接跳到await后的代码，中间的 microtask 调度过程被隐藏。若想观察 microtask 队列，需在Promise.resolve().then()的then回调内设断点。

5.2 Jest 中测试 async 函数的三种方式

Jest 对async函数有原生支持，但写法不当会导致测试失败：

// ✅ 正确：返回 Promise test('fetches data', async () => { mockFetch.mockResolvedValue({ json: () => Promise.resolve({ id: 1 }) }); const data = await fetchData(); expect(data.id).toBe(1); }); // ✅ 正确：使用 done 回调（旧式） test('fetches data', (done) => { fetchData().then(data => { expect(data.id).toBe(1); done(); }); }); // ❌ 错误：忘记 await，测试会立即通过 test('fetches data', () => { fetchData().then(data => expect(data.id).toBe(1)); // 测试函数结束，Promise 还未 resolve });

关键原则：Jest 会等待测试函数返回的 Promise settle。因此，async test()是最推荐的方式，简洁且不易出错。

5.3 性能监控：用 Performance API 测量 await 开销

await本身开销极小（纳秒级），但其背后的 Promise 构造、microtask 插入、状态变更有可观测成本：

// 测量单个 await 的 microtask 开销 function measureAwaitOverhead() { const start = performance.now(); const p = Promise.resolve(); p.then(() => { const end = performance.now(); console.log('microtask overhead:', end - start, 'ms'); }); } // 测量 await 链的总延迟 async function benchmarkAwaitChain() { const t0 = performance.now(); await Promise.resolve(); await Promise.resolve(); await Promise.resolve(); const t1 = performance.now(); console.log('3x await total:', t1 - t0, 'ms'); }

经验数据：在现代 Chrome 中，单个await Promise.resolve()的 microtask 开销约 0.01ms，但 100 个连续await可能累积到 0.5ms+，这对 60fps 动画（每帧 16.6ms）是不可忽视的。

5.4 错误监控：捕获全局 unhandledrejection

生产环境必须监听未处理的 Promise rejection：

window.addEventListener('unhandledrejection', event => { // event.reason 是 rejection 的原因 // event.promise 是被 reject 的 Promise console.error('Unhandled rejection:', event.reason); // 上报到监控系统 reportError({ type: 'unhandledrejection', reason: event.reason.toString(), stack: event.reason.stack, url: window.location.href }); });

注意：unhandledrejection事件在 Promise rejection 后 1 个 microtask 阶段触发。若在await后立即catch，则不会触发此事件。这是验证错误处理是否完备的黄金指标。

6. 未来演进与替代方案：async/await 的边界在哪里？

6.1 TC39 提案：Awaited 类型与更严格的类型检查

TypeScript 4.5 引入了Awaited<T>工具类型，用于精确推导await后的类型：

type ApiResponse = { data: string }; type ApiPromise = Promise<ApiResponse>; // 不用 Awaited，类型是 Promise<ApiResponse> declare function fetchApi(): ApiPromise; // 用 Awaited，类型是 ApiResponse type Result = Awaited<ReturnType<typeof fetchApi>>; // ApiResponse

这解决了async函数返回类型模糊的问题，让类型系统能精确追踪await链。未来，Awaited可能成为 JavaScript 原生类型，进一步强化async/await的静态保障。

6.2 WebAssembly 与 async：计算密集型任务的新范式

async/await无法解决 CPU 密集型任务的阻塞问题。WebAssembly 提供了真正的并行能力：

// WASM 模块中的计算函数（非阻塞） const wasmModule = await WebAssembly.instantiateStreaming(fetch('calc.wasm')); const result = await wasmModule.instance.exports.heavyCalc(1000000); // 与 async/await 无缝集成 async function processData() { const data = await fetch('/data.json').then(r => r.json()); const processed = await wasmModule.instance.exports.process(data); // 非阻塞调用 return processed; }

WASM 的await不是调度 microtask，而是等待一个由浏览器线程池管理的异步计算完成，这是async/await在性能边界