使用Promise.then与async-await时栈追踪差异原因咨询

两种写法的栈信息差异本质来自执行时栈帧的留存逻辑不同，和JS引擎的异步栈优化直接相关：

1. 纯Promise.then写法的执行逻辑
   示例中的普通函数a是完全同步执行的：调用a()时，b().then(() => c())这行只会做一件事——把传给then的匿名回调注册为b()这个Promise resolve后的微任务，注册完成后a就执行完毕，对应的栈帧直接从调用栈弹出退出。
   等微任务队列轮到这个回调执行时，调用栈里只有微任务调度入口、这个匿名回调、以及回调内部调用的c函数，早就没有a的栈帧了，所以错误栈里只能看到c和匿名回调的位置，看不到a。示例栈信息里的at <anonymous>:10:17就是那个没有显式命名的then回调。
2. async/await写法的执行逻辑
   async/await虽然本质是Promise的语法糖，但V8引擎（Chrome、Node.js使用的JS引擎）对它做了专门的异步调用栈留存优化：当async函数执行到await时，引擎不会直接销毁当前函数的栈帧，而是会把a函数的执行上下文挂起、留存调用链信息，等await的Promise resolve后，再恢复a的上下文继续执行后续代码。
   这时候c()抛错，执行栈能直接追溯到恢复后的a函数栈帧，所以栈信息里会明确显示a的调用位置。
   要注意这个优化不是ECMAScript标准强制要求的，是引擎层面做的体验增强——早期版本的V8里async/await也拿不到完整的异步栈，是后续迭代专门新增的特性。

• 日常业务开发中，优先用async/await是完全合理的选择：除了更完整的错误栈，它的代码流和同步写法逻辑一致，不管是打断点调试、还是梳理执行路径，成本都比长串的then链低很多。
• 不需要把这个当成绝对准则：then链式写法在处理并行Promise、动态组装Promise链的场景下依然有可读性优势，只要你给传给then/catch的回调都设置明确的函数名、所有Promise链末尾都固定加错误捕获，也能很大程度解决栈信息不清晰的问题，没必要完全弃用then写法。
• 不管用哪种写法，一定要在Promise链的最末端加错误捕获，未捕获的Promise rejection不管栈信息全不全，排查成本都会很高。

• V8引擎的异步栈追踪实现原理：核心是在异步任务挂起时，轻量记录当前的调用链上下文，错误抛出时把留存的异步上下文和当前同步栈拼接成完整栈信息，实现时做了特殊处理不会造成额外的内存泄漏。
• JS事件循环的调用栈生命周期：搞清楚同步执行阶段、异步回调注册阶段、微任务/宏任务执行阶段的栈帧入栈出栈规则，就能自己推导绝大多数异步场景的栈输出结果。
• 不同运行时的异步栈实现差异：除了Chrome的V8，火狐的SpiderMonkey、Safari的JavaScriptCore对异步栈的采集逻辑各有不同，低版本Node.js、旧浏览器里就算用async/await也可能拿不到完整栈，本质都是运行时有没有实现对应的采集优化。

内容的提问来源于stack exchange，提问作者Joji