promise.then回调执行时调用栈不包含resolve/reject路径，而是以微任务形式在同步任务结束后由事件循环执行，栈中仅见回调自身及微任务调度入口。
Promise.then 的回调函数执行时，调用栈中**不包含 Promise 内部的 resolve/reject 调用路径**，而是以微任务（microtask）形式入队后，在当前同步任务结束后、下一个宏任务开始前，由事件循环清空微任务队列时压入调用栈——此时调用栈只反映当前正在执行的 then 回调本身，以及它直接调用的函数。
微任务入队与调用栈分离
当 Promise 状态变为 fulfilled 或 rejected 时，.then 或 .catch 注册的回调会被作为微任务加入微任务队列（如 PromiseJobs 队列），但不会立即执行。JS 引擎会继续执行完当前同步代码（包括所有嵌套调用），等调用栈完全清空后，才从微任务队列中取出第一个任务执行。
- 这意味着你在 debugger 中断点停在 then 回调里时，调用栈顶部是该回调函数，下面通常只有浏览器/Node.js 的微任务调度入口（如 promiseReactionJob 或 runMicrotasks），而看不到之前触发 resolve() 的那条同步链
- 例如：funcA → funcB → resolve() → （同步结束）→ 微任务执行 → then 回调。你在 then 里看到的调用栈是：thenCallback ← promiseReactionJob，而不是 funcA → funcB → resolve()
调用栈中看不到 Promise 构造器或 resolve 调用者
Promise 构造器中的 executor 函数（即 new Promise((resolve) => {...}) 里的函数）是同步执行的，但它的 resolve() 调用只是标记状态并排队微任务，并不“驱动”后续 then 的执行栈。因此：
- resolve() 本身执行完就返回，不会延续到 then 回调的栈帧中
- 即使 resolve(1) 是在深层函数调用中触发的（比如 resolve(x()) → x() → y()），y() 和 x() 的栈帧早已弹出，不会出现在 then 回调的调用栈里
- 你可以用 console.trace() 在 then 回调里打印，验证调用栈起点就是该回调自身
对比 setTimeout（宏任务）的调用栈差异
setTimeout 的回调执行时，调用栈底部会有类似 setTimeout handler 或 timer callback 的宿主环境入口；而 then 回调的底部通常是更底层的微任务调度机制名（如 Chrome 中是 promiseReactionJob，Node.js 中可能是 process.nextTick 或 promiseInit 相关）。这说明两者虽都是异步，但调度层级和栈痕迹不同。
- 微任务调度比宏任务更早介入事件循环，所以 then 总比 setTimeout(fn, 0) 先执行，且调用栈结构也更“贴近引擎内部”
- 无法通过调用栈反推是哪个 resolve() 触发了当前 then —— 这是设计使然，也是 Promise 抽象的价值所在
调试时如何关联上下文？
既然调用栈断开了，想追踪源头就得靠其他手段：
- 在 resolve 前加日志或 debugger，配合异步调用链标识（如打上 traceId）
- 利用 Promise.prototype.catch 捕获未处理 rejection 并打印 stack（注意：fulfilled 分支不抛错，stack 无帮助）
- 现代 DevTools 支持“Async Stack Trace”，开启后能在 then 回调中看到异步关联的初始位置（依赖 V8 的 async_hooks 或 Chromium 的跟踪能力，非标准 JS 行为）
- 避免过度依赖调用栈分析 Promise 流程，更适合用状态机思维 + 日志 + 工具链（如 why-promise-rejected）定位问题
