async函数调用栈是断点式重建的，每次await后恢复执行都在全新上下文中，而非原栈帧延续；await后续代码作为微任务执行，与原函数物理隔离。
async 函数内部的调用栈不是连续延展的，而是“断点式重建”的——每次 await 暂停后恢复执行，都发生在全新的函数执行上下文中，而非原栈帧的延续。
async 函数执行时上下文立即销毁
当一个 async 函数遇到 await 时，它不会冻结当前执行上下文；相反，引擎会立即清空该函数对应的上下文，并把后续代码包装成微任务排队。这意味着：
- await 表达式之后的语句，不再属于原始函数调用栈中的帧
- 恢复执行时，JS 引擎创建一个全新的函数执行上下文，包含独立的 VariableEnvironment 和 LexicalEnvironment
- 闭包变量仍可访问，靠的是 outer 引用链，不是栈帧保留
调用栈只反映同步路径，不体现 await 链
你用 console.trace() 或 new Error().stack 查看的，永远是当前同步执行路径上的栈帧。例如：
async function a() { console.trace(); await b(); }
async function b() { console.trace(); await c(); }
async function c() { console.trace(); }
三次 console.trace() 输出的栈深度都极浅（通常只有 a → b → c 的一层或两层），因为每个 await 都导致上下文退出，下一次 trace 是在新上下文中触发的。这不是“栈被截断”，而是根本没形成深层嵌套。
await 后续逻辑本质是微任务，不是栈延续
await x() 实际等价于：
- 把 x() 返回的 Promise 注册 .then 回调
- 该 .then 回调被放入微任务队列
- 当前同步代码跑完，事件循环立刻执行微任务队列中所有任务
所以看似“接着执行”的代码，其实是另一个微任务里的新函数调用，和原函数调用栈物理隔离。这也是为什么多个 await 之间可能被其他 Promise.then 插入——它们同属微任务队列，按注册顺序排队，而非栈内顺序。
调试异步堆栈需借助额外机制
浏览器 DevTools 的 “Async Stack Trace” 功能能串联出逻辑调用链，但它不是读取真实调用栈，而是通过：
- 运行时注入 trace ID（如 Chrome 的 async_id）
- 利用 AsyncLocalStorage（Node.js）或 Zone.js（旧方案）捕获上下文快照
- 将微任务回调与发起它的 await 关联起来，人工重建链路
纯靠 new Error().stack 只能看到当前微任务入口点，无法回溯到最初的 async 调用位置。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
