异步代码中回调函数调用栈的获取与恢复机制探究

你的猜测并不准确——回调函数的调用栈不是完整存储在堆中，执行时再恢复的，背后的机制要分真实执行逻辑和调试器展示两个层面来看：

真实的执行上下文与调用栈逻辑 #

当你的同步代码（y(1) → x() → exe → q()）执行完成后，这些函数的执行上下文都会依次从调用栈弹出并销毁，此时调用栈是空的。

Promise.resolve(5)完成后，xCallback被推入微任务队列。当它开始执行时：

• 只会把xCallback的执行上下文压入当前空的调用栈，此时真实的调用栈里只有xCallback这一项。
• 堆中存储的是xCallback这个函数对象，以及它创建时捕获的词法环境（比如对resolve的引用，来自exe函数的作用域），但这不是调用栈的副本，只是变量作用域的关联信息。

调试器的“模拟调用栈” #

你看到的xCallback -> exe -> x -> y -> anonymous调用栈，是调试器为了方便开发者追溯回调来源而模拟出来的回溯链，不是真实的调用栈恢复：
调试器会通过函数的词法环境、Promise链的关联关系，反向推导这个回调是从哪条调用路径触发的，然后把这些历史函数拼接成看起来像调用栈的结构，让你能清晰看到回调的起源，但这并不是执行时真实存在的调用栈。

简单来说：调用栈是执行时的临时内存结构，函数执行完就销毁，不会存在堆里；堆里只存函数对象和作用域关联信息，调试器的调用栈展示是基于这些信息的回溯模拟。

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