与浏览器事件循环的核心差异

Node.js 与浏览器虽然都使用事件循环来处理异步操作，但因为它们面向的场景完全不同，底层的实现机制也存在显著差异。理解这些差异，能帮助你避免在两个环境之间迁移代码时踩坑。

差异根源：面向场景不同

浏览器的事件循环是为了协调用户交互、DOM 渲染、网络请求等浏览器特定任务。而 Node.js 的事件循环是为了高效处理文件 I/O、网络 I/O、数据库查询等服务器端任务。这就导致了两者在任务分阶段处理、执行时机和优先级上有着本质区别。

宏任务的划分方式不同

浏览器中，宏任务（macrotask）是一个相对扁平的队列，主要包括：setTimeout / setInterval、I/O 回调、UI 渲染等。每次事件循环会取出一个宏任务执行，然后清空所有微任务，再进行一次渲染，然后进入下一轮循环。

Node.js 则将不同类型的宏任务划分到六个不同的阶段中：

   ┌───────────────────────────┐
┌─>│           timers          │  执行 setTimeout、setInterval 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │  执行延迟到下一循环的 I/O 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │  内部使用
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           poll            │  检索新的 I/O 事件；执行 I/O 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │           check           │  执行 setImmediate 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │  执行关闭事件回调（如 socket.on('close')）
   └───────────────────────────┘

每一轮事件循环会依次经过这六个阶段，每个阶段都会执行各自队列中的回调。关键是：微任务在每个阶段之间被检查并清空，而不是整个事件循环结束后。

微任务执行时机的差异

在浏览器中，微任务（如 Promise.then/catch/finally、MutationObserver）会在一个宏任务执行完之后立即被全部清空，然后再进行 UI 渲染。换句话说，微任务在宏任务与渲染之间执行。

在 Node.js 中（版本 11 之前），微任务是在切换阶段时执行的，即在当前阶段的所有回调执行完之后，才会清空微任务队列。从 Node.js 11 开始，为了与浏览器行为对齐，微任务改为在每个定时器和 I/O 回调执行完之后立即清空，这使得行为的可预测性有所提高，但与浏览器仍然有细微差别。

process.nextTick：Node.js 独有的优先级

Node.js 还有一个特殊的存在：process.nextTick。从技术上讲，它既不是宏任务，也不是微任务，而是属于当前操作结束后立即执行的队列，优先级甚至高于微任务。

console.log('1');

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

Promise.resolve().then(() => {
  console.log('Promise');
});

console.log('2');

// 输出：1 2 nextTick Promise

在每一轮事件循环的任何阶段，当前操作执行完毕后，会先检查 nextTick 队列和微任务队列，nextTick 队列先于 Promise 微任务队列执行。这一机制在浏览器中完全不存在。

一个经典陷阱：nextTick 设计之初是为了立即调度一个回调，让它能在当前事件循环阶段结束后立刻执行，但如果递归调用 process.nextTick，会形成类似死循环的效果，直接阻塞事件循环。实际操作中应谨慎使用。

setImmediate 与 setTimeout(fn, 0) 的反直觉行为

浏览器中没有 setImmediate。在 Node.js 的世界里，setImmediate 和 setTimeout(fn, 0) 看起来都像是“尽快执行”，但它们的执行顺序却出人意料地不确定：

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

在 Node.js 的主模块中直接运行这段代码，输出顺序可能是 timeout -> immediate，也可能是 immediate -> timeout。原因是：

如果进入 timers 阶段时，系统时间尚未达到 setTimeout 的到期时间（即使设为 0，实际阈值是 1ms），它会被推迟到下一轮循环的 timers 阶段执行。
而 setImmediate 总是在当前轮次的 check 阶段执行。

当这段代码放在一个 I/O 回调中时，行为就变得确定——setImmediate 始终先于 setTimeout(fn, 0) 执行，因为 I/O 回调在 poll 阶段执行，执行完后紧接着进入 check 阶段。

实际开发中的关注点

向后端迁移代码时：将依赖 setTimeout 顺序的前端代码迁移到 Node.js 时，需要特别测试，不要假设浏览器里的执行逻辑在 Node 里也完全相同。
合理使用 process.nextTick：有极少数场景确实需要比微任务更高的优先级（例如在异步流程中确保某个状态先被更新，再触发后续 Promise 链），但要警惕递归调用。
事件循环阻塞诊断：在 Node.js 中，如果一个阶段中的回调数量巨大或耗时过长，后续阶段（甚至包括微任务）都会被延迟。此时可以通过 eventLoopUtilization（Node.js 14.12+）等工具监测延迟。

总结：浏览器事件循环的焦点是用户界面和渲染，而 Node.js 事件循环的焦点是 I/O 吞吐量和多阶段调度。掌握它们不同的任务划分和执行时机，是写出可靠全栈代码的基础。