async/await执行机制解析：不同JS引擎调用栈差异探究

测试代码 #

async function loop() {
  for (let i = 0; i < 3; i++) {
    console.log(i, new Error("").stack);
    await 1;
  }
}

loop();

不同引擎的调用栈输出 #

Node.js（基于V8引擎） #

0 Error
    at loop (file:///Users/user/Desktop/test.mjs:3:19)
    at file:///Users/user/Desktop/test.mjs:8:1
    at ModuleJob.run (node:internal/modules/esm/module_job:217:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:308:24)
    at async loadESM (node:internal/process/esm_loader:42:7)
    at async handleMainPromise (node:internal/modules/run_main:66:12)
1 Error
    at loop (file:///Users/user/Desktop/test.mjs:3:19)
2 Error
    at loop (file:///Users/user/Desktop/test.mjs:3:19)

可见第一次循环时调用栈完整，await后的两次循环仅保留loop函数自身的调用栈上下文，全局调用栈信息丢失。

Bun（基于JavaScriptCore引擎） #

0 Error: 
    at <anonymous> (/Users/user/Desktop/test.mjs:3:10)
    at loop (/Users/user/Desktop/test.mjs:1:22)
    at module code (/Users/user/Desktop/test.mjs:5:5)
1 Error: 
    at <anonymous> (/Users/user/Desktop/test.mjs:3:10)
2 Error: 
    at <anonymous> (/Users/user/Desktop/test.mjs:3:10)

此处await后的循环甚至丢失了loop函数的调用栈上下文，仅显示<anonymous>。

核心疑问 #

已知await会将后续任务推入微任务队列，等待调用栈中同步代码执行完毕后再执行，调用栈会被清空。但需要明确：await之后的代码是仍在原函数中执行，还是会创建继承原上下文的新函数？为何不同引擎的调用栈表现存在差异？

解析 #

await的底层执行逻辑 #

await之后的代码不会创建新函数，而是在原异步函数的执行上下文恢复后继续执行。

异步函数执行到await时，会暂停当前函数执行，保存当前的执行上下文（包括变量环境、作用域链等），然后将后续代码包装成微任务放入微任务队列。当调用栈清空、同步任务执行完成后，JS引擎取出微任务执行，此时会恢复之前保存的异步函数执行上下文，继续执行await之后的代码。

不同引擎调用栈差异的原因 #

调用栈输出的差异本质是引擎对调用栈信息的保留策略不同，并非执行上下文本身存在差异：

• V8引擎（Node.js）：恢复异步函数执行时，会保留当前函数的调用栈帧（即loop函数的栈信息），但不会保留原全局调用栈（因为原调用栈已被清空，微任务执行时的调用栈起点就是恢复的异步函数帧），因此await后仍能看到loop的栈信息。
• JavaScriptCore引擎（Bun）：处理await后的微任务时，可能将后续执行代码以匿名函数形式调度，或未保留原函数的栈帧引用，导致调用栈仅显示<anonymous>。但实际上代码依然在原异步函数的执行上下文中运行——可通过测试await后访问函数内变量的方式验证，变量能正常获取，证明上下文未丢失，只是栈信息的记录方式不同。

关键结论 #

await之后的代码始终在原异步函数的执行上下文中继续执行，并未创建新函数。不同引擎的调用栈差异只是引擎在记录和暴露调用栈信息时的实现细节不同，核心执行逻辑符合ECMAScript规范。

内容的提问来源于stack exchange，提问作者Łukasz Karczewski