Node.js事件循环中EventEmitter回调会在哪些阶段执行？

你的核心误解在于把EventEmitter的回调和Node.js的异步任务回调（比如fs.readFile、定时器回调）混为一谈了。EventEmitter的回调并不是异步任务，它会在emit()被调用的当前上下文里同步执行，这就是为什么它会出现在各个事件循环阶段的输出之后。

关键原理：EventEmitter.emit()是同步操作 #

当你调用eventEmitter.emit()时，Node.js会立即遍历该事件绑定的所有回调函数，同步执行它们——这和你直接调用一个普通函数没有本质区别，不会把回调放到任何异步队列（比如timers、check、poll队列）里等待后续阶段处理。

结合你的测试代码和输出逐一分析 #

我们对应输出顺序拆解每个场景：

1. 同步代码阶段
   最外层setTimeout的回调里，首先执行console.log('sync')，这是同步代码，所以输出第一行是sync。

2. process.nextTick队列
   process.nextTick的回调会在当前同步代码执行完成后立即处理（属于微任务队列，优先级高于Promise）。执行回调时调用eventEmitter.emit()，同步触发事件回调，所以输出顺序是：

   process.nextTick
   <----- an event occurred! ---> emit inside process.nextTick
   

3. Promise微任务队列
   Promise的then回调属于微任务，在process.nextTick队列处理完后执行。同样，调用emit()时同步执行事件回调，输出顺序：

   Promise.resolve()
   <----- an event occurred! ---> emit inside Promise.resolve()
   

4. check阶段（setImmediate）
   setImmediate的回调会在事件循环的check阶段执行。执行回调时调用emit()，同步触发事件回调，所以输出：

   setImmediate
   <----- an event occurred! ---> emit inside setImmediate 1
   

5. timers阶段（setTimeout）
   两个setTimeout的回调分别在timers阶段执行（先处理延迟0的，再处理延迟5的）。每次调用emit()都会同步执行事件回调，所以输出：

   setTimeout 0
   <----- an event occurred! ---> emit inside setTimeout 0
   setTimeout 5
   <----- an event occurred! ---> setInterval inside setTimeout 5
   

6. poll阶段（fs.readFile）
   fs.readFile的异步I/O回调会在poll阶段执行，调用emit()后同步触发事件回调，输出：

   fs.readFile
   <----- an event occurred! ---> emit inside fs.readFile
   

总结 #

EventEmitter的回调不是异步任务，不会进入事件循环的异步队列等待调度。它的执行时机完全由emit()的调用时机决定——不管emit()是在同步代码里，还是在某个事件循环阶段的异步回调里，只要调用emit()，绑定的回调就会立即同步执行，这就是为什么你会看到它出现在各个阶段的输出之后。

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