一道"经典"的 Event Loop 面试题，背了八股文的你以为稳了，结果一运行却被 ESM 背刺。本文带你深挖 Node.js 事件循环中一个 99% 的人都不知道的坑：同样的代码，CJS 和 ESM 输出顺序竟然不一样。

前言

如果你准备过前端/Node.js 面试，大概率刷到过这类题目：

setImmediate(() => {
    console.log(1);
});

process.nextTick(() => {
    console.log(2);
    process.nextTick(() => {
        console.log(6);
    });
});

console.log(3);

Promise.resolve().then(() => {
    console.log(4);
    process.nextTick(() => {
        console.log(5);
    });
});

你自信地写下答案：3 → 2 → 6 → 4 → 5 → 1。

面试官微微一笑，说："没问题，回去等通知吧。"

你心满意足地回家，顺手建了个项目想验证一下，npm init，改了下 package.json，node index.js 一跑——

3
4
2
5
6
1

你揉了揉眼睛，又跑了一遍。没错，4 跑到 2 前面去了。

你开始怀疑人生：是我八股文背错了？还是 Node.js 出 bug 了？

都不是。是 ESM 在背后捅了你一刀。

---

一、先复习：Node.js 事件循环到底怎么转的

在搞清楚这个坑之前，我们得先把 Node.js 的事件循环机制理清楚。这部分是基础，老手可以快速跳过，但建议还是扫一遍，因为后面的分析会用到。

1.1 事件循环的六个阶段

Node.js 的事件循环基于 libuv，分为以下几个阶段，每一轮循环（tick）按顺序执行：

   ┌───────────────────────────┐
┌─>│           timers          │  ← setTimeout / setInterval 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │  ← 系统级回调（如 TCP 错误）
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │  ← 内部使用
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           poll            │  ← I/O 回调（fs.readFile 等）
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           check           │  ← setImmediate 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │      close callbacks      │  ← socket.on('close') 等
│  └───────────────────────────┘

1.2 微任务的位置

在 Node.js v11 之后，每个阶段之间以及每个宏任务执行之后，都会清空微任务队列。微任务分为两类：

队列	API	优先级
nextTick 队列	process.nextTick()	高
微任务队列	Promise.then() / queueMicrotask()	低

也就是说，在传统认知中（CJS 模式下），优先级排序是：

同步代码 > process.nextTick > Promise 微任务 > 宏任务（timers / check / ...）

这也是为什么你面试时会回答 3 → 2 → 6 → 4 → 5 → 1 的原因——nextTick 队列会在 Promise 微任务之前被清空。

1.3 微任务递归清空

一个重要的细节：nextTick 队列在清空时，如果回调中又注册了新的 nextTick，会在同一轮继续清空，直到队列为空。Promise 微任务也是同理。整个流程：

1. 清空 nextTick 队列（递归）
2. 清空 Promise 微任务队列（递归）
3. 如果上述步骤产生了新的 nextTick 或微任务，回到 1
4. 全部清空后，进入下一个事件循环阶段

到这里，一切都很"标准"，也符合绝大多数八股文的描述。

---

二、验证"标准答案"——CJS 模式

我们先在 CJS 模式下跑一下，证明八股文没有骗你。

创建一个 test-cjs.js（注意：不要在 package.json 里设置 "type": "module"）：

// test-cjs.js（CommonJS 模式）
setImmediate(() => {
    console.log(1);
});

process.nextTick(() => {
    console.log(2);
    process.nextTick(() => {
        console.log(6);
    });
});

console.log(3);

Promise.resolve().then(() => {
    console.log(4);
    process.nextTick(() => {
        console.log(5);
    });
});

执行：

node test-cjs.js

输出：

3
2
6
4
5
1

完美，和八股文一模一样。我们来走一遍流程：

第一步：执行同步代码

• setImmediate(cb) → 注册到 check 阶段队列
• process.nextTick(cb) → 注册到 nextTick 队列（打印 2）
• console.log(3) → 输出 3
• Promise.resolve().then(cb) → 注册到微任务队列（打印 4）

此时队列状态：

nextTick 队列：[cb(2)]
微任务队列：  [cb(4)]
check 队列：  [cb(1)]

第二步：清空 nextTick 队列

• 执行 cb(2) → 输出 2，并注册 nextTick(cb(6))
• 队列没清空，继续 → 执行 cb(6) → 输出 6

第三步：清空微任务队列

• 执行 cb(4) → 输出 4，并注册 nextTick(cb(5))
• 微任务执行完毕，检查 nextTick → 执行 cb(5) → 输出 5

第四步：进入事件循环 check 阶段

• 执行 setImmediate 回调 → 输出 1

最终：3 → 2 → 6 → 4 → 5 → 1 ✅

---

三、翻车现场——ESM 模式

现在，我们做一件"无害"的事情——在 package.json 里加上一行：

{
  "type": "module"
}

代码一个字都不改，再跑一次：

node index.js

输出：

3
4
2
5
6
1

4 跑到 2 前面去了！Promise 微任务比 nextTick 先执行了！

等等，不是说好了 nextTick > Promise 吗？

这并不是 Node.js 的 bug，这是 ESM 模块系统的执行机制 导致的必然结果。

---

四、为什么 ESM 会改变执行顺序？

这是本文的核心。要理解这个差异，必须搞清楚 CJS 和 ESM 在 Node.js 中的执行方式有什么本质不同。

4.1 CJS 的执行方式

在 CJS 模式下，Node.js 的执行流程大致是：

1. 同步加载模块（require 是同步的）
2. 同步执行模块代码
3. 模块代码执行完毕，进入事件循环
4. 事件循环开始前，先清空 nextTick 队列，再清空微任务队列

关键点：模块代码的执行是在 Node.js 的"主执行流"中完成的。执行完毕后，Node.js 通过自己的调度逻辑先处理 nextTick，再处理 Promise 微任务。

4.2 ESM 的执行方式

ESM 就完全不一样了。根据 ECMAScript 规范，ES Module 的加载和求值是 异步 的：

1. 解析模块依赖图（静态分析 import/export）
2. 异步加载所有模块
3. 按照依赖顺序对模块进行求值（evaluate）

关键来了：ESM 模块的求值（evaluate）过程本身就是在一个微任务（microtask）上下文中进行的。

这意味着什么？当你的 ESM 代码执行时，它已经处在 V8 引擎的微任务调度体系中了。代码执行完毕后：

1. V8 引擎会先执行自己的微任务检查点（microtask checkpoint）
2. Promise 微任务是 V8 原生管理的，所以会被 V8 先消费
3. 然后控制权交还给 Node.js
4. Node.js 再清空 nextTick 队列

用一张对比图来看：

CJS 执行完毕后的清空顺序：
┌─────────────────────────────────┐
│  Node.js 接管                    │
│  1. 清空 nextTick 队列            │  ← Node.js 自己的机制
│  2. 清空 Promise 微任务队列        │  ← V8 的微任务
│  3. 进入事件循环                   │
└─────────────────────────────────┘

ESM 执行完毕后的清空顺序：
┌─────────────────────────────────┐
│  V8 微任务检查点触发               │
│  1. 清空 Promise 微任务队列        │  ← V8 先动手了！
│  2. Node.js 接管                  │
│  3. 清空 nextTick 队列            │  ← Node.js 的 nextTick 被延后了
│  4. 进入事件循环                   │
└─────────────────────────────────┘

本质区别：在 CJS 中，Node.js 拥有微任务调度的主动权，所以它能让 nextTick 先走；而在 ESM 中，V8 引擎的微任务检查点先于 Node.js 的 nextTick 调度触发，所以 Promise 反而先执行了。

4.3 一句话总结

process.nextTick 是 Node.js 的"私货"，不属于 ECMAScript 标准。在 ESM 模式下，V8 引擎遵循标准的微任务执行机制，自然不会优先照顾 Node.js 的私货。

---

五、用代码证明这不是玄学

为了彻底证实这个结论，我们做一组最简实验——只用 nextTick 和 Promise 对比：

实验 1：CJS 模式

node -e "
process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));
"

输出：

nextTick
promise

✅ nextTick 先于 Promise

实验 2：ESM 模式

node --input-type=module -e "
process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));
"

输出：

promise
nextTick

✅ Promise 先于 nextTick

同样的代码，两行都没改，只是切换了模块系统，执行顺序就反过来了。

实验 3：在事件循环内部（两者一致）

// 无论 CJS 还是 ESM，事件循环内部的行为是一致的
setTimeout(() => {
    process.nextTick(() => console.log('nextTick'));
    Promise.resolve().then(() => console.log('promise'));
}, 0);

输出（两种模式都一样）：

nextTick
promise

这说明：ESM 只影响顶层代码（Top-Level）的微任务执行顺序，一旦进入事件循环内部，nextTick 和 Promise 的优先级关系恢复正常。

---

六、回到那道面试题——ESM 下的完整解析

现在我们用 ESM 的规则重新分析原题：

setImmediate(() => {
    console.log(1);
});

process.nextTick(() => {
    console.log(2);
    process.nextTick(() => {
        console.log(6);
    });
});

console.log(3);

Promise.resolve().then(() => {
    console.log(4);
    process.nextTick(() => {
        console.log(5);
    });
});

第一步：执行同步代码

和 CJS 完全一样：

• 注册 setImmediate(cb(1)) → check 队列
• 注册 nextTick(cb(2)) → nextTick 队列
• 输出 3
• 注册 Promise.then(cb(4)) → 微任务队列

队列状态：

nextTick 队列：[cb(2)]
微任务队列：  [cb(4)]
check 队列：  [cb(1)]

第二步：V8 微任务检查点（ESM 的关键差异！）

因为是 ESM 模式，V8 的微任务检查点先触发：

• 执行 cb(4) → 输出 4，注册 nextTick(cb(5))

此时队列状态：

nextTick 队列：[cb(2), cb(5)]
微任务队列：  []（已清空）
check 队列：  [cb(1)]

第三步：Node.js 清空 nextTick 队列

• 执行 cb(2) → 输出 2，注册 nextTick(cb(6))
• 执行 cb(5) → 输出 5
• 执行 cb(6) → 输出 6

此时队列状态：

nextTick 队列：[]（已清空）
微任务队列：  []
check 队列：  [cb(1)]

第四步：进入事件循环 check 阶段

• 执行 setImmediate 回调 → 输出 1

最终：3 → 4 → 2 → 5 → 6 → 1 ✅

---

七、面试怎么答？

如果你在面试中遇到这道题，我建议分三层回答：

第一层：给出标准答案

在 CJS 模式下，输出顺序是 3 → 2 → 6 → 4 → 5 → 1。因为同步代码优先执行，然后 process.nextTick 队列会在 Promise 微任务之前被清空，最后才是 setImmediate 宏任务。

第二层：主动提出 ESM 的差异

但如果这段代码运行在 ESM 模式下（"type": "module" 或 .mjs 文件），输出顺序会变成 3 → 4 → 2 → 5 → 6 → 1。因为 ESM 模块的求值本身处于 V8 的微任务上下文中，Promise 微任务会被 V8 引擎优先消费，先于 Node.js 的 nextTick 队列。

第三层：解释根本原因

这个差异的本质是 process.nextTick 是 Node.js 自己的调度机制，不属于 ECMAScript 标准。在 CJS 模式下，Node.js 对执行流有完全的控制权，可以让 nextTick 优先；但在 ESM 模式下，V8 引擎遵循标准的微任务执行机制，Node.js 的私有调度会被延后。不过这个差异只存在于顶层代码中，进入事件循环后两者行为一致。

这三层答出来，面试官绝对会对你刮目相看。

---

八、延伸思考

8.1 这算是 Node.js 的 Bug 吗？

不算。这是 CJS 和 ESM 两种模块系统的 设计差异 导致的必然结果。Node.js 官方文档中也有相关说明：

Microtask callbacks take priority over nextTick callbacks in this specific case because of V8's microtask checkpoint behavior during ES module evaluation.

8.2 process.nextTick 还值得用吗？

process.nextTick 在 Node.js 生态中仍然有其存在价值，比如：

• 在事件循环内部，它的优先级依然高于 Promise
• 用来确保回调在当前操作完成后、I/O 之前执行
• 在流（Stream）和 EventEmitter 中广泛使用

但考虑到 ESM 正在成为 Node.js 的主流模块系统，你需要意识到 在顶层代码中，nextTick 的优先级不再是绝对的。如果你对执行顺序有严格要求，应该通过代码结构来保证，而不是依赖 nextTick 和 Promise 的微妙优先级差异。

8.3 queueMicrotask vs process.nextTick

还有一个相关的知识点：queueMicrotask() 是 Web 标准 API，Node.js 也支持。它创建的微任务和 Promise 处于同一级别。在 CJS 中，queueMicrotask 的回调在 nextTick 之后执行；在 ESM 中，它和 Promise 一样会先于 nextTick 执行。

process.nextTick(() => console.log('nextTick'));
queueMicrotask(() => console.log('queueMicrotask'));
Promise.resolve().then(() => console.log('promise'));

CJS 输出：nextTick → queueMicrotask → promise ESM 输出：queueMicrotask → promise → nextTick

8.4 面试中常见的相关题目

理解了上面的原理后，下面这些变种你也能轻松应对：

题目 1：async/await 的执行顺序

async function foo() {
    console.log(1);
    await Promise.resolve();
    console.log(2);
}

process.nextTick(() => console.log(3));
foo();
console.log(4);

CJS 下：1 → 4 → 3 → 2 ESM 下：1 → 4 → 2 → 3

原理相同：await 后面的代码本质上就是 Promise.then，在 ESM 中会先于 nextTick 执行。

题目 2：setTimeout vs setImmediate

setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));

这道题的输出顺序是 不确定的（取决于系统调度），但如果放在 I/O 回调中，setImmediate 一定先于 setTimeout：

const fs = require('fs');
fs.readFile(__filename, () => {
    setTimeout(() => console.log('timeout'), 0);
    setImmediate(() => console.log('immediate'));
});
// 始终输出：immediate → timeout

---

九、总结

维度	CJS	ESM
模块加载	同步 (require)	异步 (import)
顶层代码执行上下文	Node.js 主执行流	V8 微任务上下文
顶层 nextTick vs Promise	nextTick 优先	Promise 优先
事件循环内部 nextTick vs Promise	nextTick 优先	nextTick 优先
"type" 设置	默认 / "commonjs"	"module"
文件扩展名	.js / .cjs	.js（需配置） / .mjs

一句话记忆：CJS 中 Node.js 说了算，nextTick 是大哥；ESM 中 V8 说了算，Promise 是大哥。但进了事件循环，nextTick 依然是大哥。

---

写在最后

这个坑之所以"阴间"，是因为：

1. 代码完全一样，只是 package.json 多了一行 "type": "module"
2. 绝大多数八股文和面试题都没有区分模块系统来讨论
3. 现在的新项目基本都用 ESM 了，所以你跑出来的结果大概率和背的不一样

下次面试官再问事件循环，别忘了反问一句："请问这段代码是跑在 CJS 还是 ESM 下？"

如果面试官愣住了——恭喜你，你已经赢了。

---

如果这篇文章帮到了你，欢迎点赞收藏，关注我获取更多 Node.js 深水区技术分享。