Promise标记为已resolved是否需要调用栈为空？

核心结论 #

1. Promise的状态变更（标记为resolved）不需要依赖空调用栈——只要调用了resolve()方法，状态会立即变更，这个调用可以发生在任何同步或异步代码中。
2. 你第一个代码中Promise一直未resolved的原因，是同步循环阻塞了事件循环，导致异步I/O的回调（用来调用resolve()）根本没机会执行。
3. debugger暂停时能看到Promise resolved，是因为后台I/O操作已经完成，且对应的回调在主线程暂停的间隙被执行，或是调试器的机制直接读取了底层操作完成后的Promise状态。

详细解释 #

为什么同步循环里Promise一直pending？

Node.js的事件循环是处理异步操作的核心。当你调用resolver.resolve4时：

• 它发起的DNS查询由libuv线程池在后台执行，不会阻塞主线程。
• 当查询完成后，libuv会把一个负责调用Promise.resolve()的回调放到事件循环的I/O阶段队列中。

但你的while循环是持续10秒的同步阻塞代码，会一直霸占主线程，事件循环根本无法进入I/O阶段执行那个回调。没有回调执行，resolve()就不会被调用，Promise自然一直处于pending状态。

为什么debugger暂停时Promise会变成resolved？

当代码暂停在debugger语句时：

• 主线程虽被暂停，但后台处理I/O的线程仍在运行，操作完成后，回调会被加入事件队列。
• 调试器在暂停状态下，会允许事件循环处理队列中的微任务/宏任务（不同环境的实现略有差异），这就给了回调执行的机会，resolve()被调用后Promise状态随即变更。
• 部分环境（比如浏览器的fetch）会在底层网络操作完成后，通过内部机制提前标记Promise状态，调试器能直接读取到这个最终状态。

验证示例 #

修改第一个代码，用setTimeout打破同步阻塞，让事件循环有机会处理回调：

const { Resolver } = require('dns').promises;
const resolver = new Resolver();

let a = resolver.resolve4('example.org');

setTimeout(() => {
  console.log(process.binding('util').getPromiseDetails(a)); // 此时会显示resolved状态
}, 100);

这段代码中，setTimeout的回调会被放到事件循环的定时器阶段，主线程不会被阻塞，DNS查询的回调能正常执行，Promise状态就能完成变更。

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