async await调用栈到底长啥样？调试时别再瞎猜了

写 async/await 代码时，你有没有遇到过这种场景：报错提示里只有一行 at Promise.then (native)，或者堆栈里全是 async function，却找不到具体哪一行触发的异步链？明明逻辑看着没问题，但一出错就卡在‘看不见’的地方——这多半是没搞清 async/await 背后的调用栈真实模样。

async 函数本身不进调用栈，await 才是关键节点

很多人以为 async function foo() {} 调用后会像普通函数一样压入调用栈。其实不然：async 函数执行时，会立即返回一个 pending 状态的 Promise，函数体内部代码被包装进微任务队列，**真正的执行时机被推迟到当前同步代码跑完之后**。所以你在 Chrome DevTools 的 Call Stack 面板里，几乎看不到 async 函数名‘稳稳坐着’，它常常一闪而过，或者干脆被 Promise 构造器遮住。

看个例子，对比普通函数和 async 函数的栈差异

先看同步版本：

function a() { return b(); }
function b() { return c(); }
function c() { throw new Error('boom'); }
a();

报错时调用栈清清楚楚：at c (xxx.js:3) at b (xxx.js:2) at a (xxx.js:1)。

再换成 async/await：

async function a() { return await b(); }
async function b() { return await c(); }
async function c() { throw new Error('boom'); }
a();

实际报错栈可能是：at c (xxx.js:3) at processTicksAndRejections (internal/process/task_queues.js:95)——中间的 a、b 消失了。为啥？因为 await 触发的不是函数调用，而是 Promise 链的 .then() 注册，V8 引擎对 async 函数做了栈帧优化（也叫“栈折叠”），默认隐藏了 await 上层的 async 包装器。

怎么让调用栈‘显形’？两个实用技巧

第一，打开 Chrome 的 Async stack traces 开关：在 DevTools → Settings → Preferences → Console 下，勾选 Enable async stack traces。刷新页面再跑上面的 async 例子，就能看到类似这样的栈：

at c (xxx.js:3)
at async b (xxx.js:2)
at async a (xxx.js:1)

第二，在关键 await 前加一句 console.trace()，比如：

async function b() {
  console.trace('即将 await c');
  return await c();
}

它会打印当前完整异步上下文，包括上层 async 函数名和行号，比单纯看报错更主动、更可控。

真实项目里的坑：try/catch 没兜住，其实是栈断了

常见写法：

async function loadData() {
  const res = await fetch('/api/user');
  const data = await res.json(); // 这里可能抛 SyntaxError
  return data;
}

try {
  loadData(); // 忘了 await！
} catch (e) {
  console.log(e); // 永远进不来
}

因为 loadData() 返回的是 Promise，不是错误对象，错误被抛到了 Promise rejection 队列里，主线程的 try/catch 根本捕获不到。这时候调用栈里也看不到 loadData，只有 Uncaught (in promise) SyntaxError。解决方法很简单：加 await，或给 Promise 加 .catch()。

小结一句话：async/await 的调用栈不是‘消失’了，是藏在微任务链里等你开灯照

别指望它像同步代码那样直来直去；理解它的异步本质，善用 DevTools 的 async 栈追踪，配合手动 trace 和规范的 Promise 错误处理，才能真正把 async 代码的执行流攥在手里。