翻译了一个关于 Node.js 事件循环很棒的系列文章，共 5 篇

好文章

大神，我被 event loop 的一个问题卡住了，可否帮忙解答一下，感谢
https://www.v2ex.com/t/536584

@nikolausliu 不好意思，回复晚了。
说实话，我一开始看到你的问题也有点愣，我在我的电脑 (macbook pro / node v10.8.0) 上运行是和你得到的结果一致。如何解释这个问题我觉得需要深入到 libuv 的源码才能解释清楚，所以我手动编译了两个版本的 node，一个是 11.0.0, 一个是 10.8.0, 发现手动编译的 node 执行是符合像上面文章的 IO 处理中所说的：
(v2 貌似贴不了图，我复制一下输出结果)：
$ ./node example.js
process: 9925.402ms
timer
io
setImmediate

example.js 的内容就是你提供的脚本的内容，而且我也通过修改 libuv 底层代码，打印出来看执行顺序，输出结果如下：手动编译使用的 libuv 版本是 1.23.2



===== EVENT LOOP ROUND 1 =====


[uv__update_time]: execute


[uv__run_timers]: before execute


[uv__run_timers]: after execute


[uv__run_pending]: before execute


[uv__run_pending]: after execute


[uv__run_idle]: before execute


[uv__run_idle]: after execute


[uv__run_prepare]: before execute


[uv__run_prepare]: after execute


[uv__io_poll]: before execute


timeout -1
process: 9986.677ms


===== EVENT LOOP ROUND 2 =====


[uv__update_time]: execute


[uv__run_timers]: before execute
timer


[uv__run_timers]: after execute


[uv__run_pending]: before execute


[uv__run_pending]: after execute


[uv__run_idle]: before execute


[uv__run_idle]: after execute


[uv__run_prepare]: before execute


[uv__run_prepare]: after execute


[uv__io_poll]: before execute


timeout 0
io


[uv__io_poll]: after execute


[uv__run_check]: before execute
setImmediate


[uv__run_check]: after execute


===== EVENT LOOP ROUND 3 =====


[uv__update_time]: execute


[uv__run_timers]: before execute


[uv__run_timers]: after execute


[uv__run_pending]: before execute


[uv__run_pending]: after execute


[uv__run_idle]: before execute


[uv__run_idle]: after execute


[uv__run_prepare]: before execute


[uv__run_prepare]: after execute


[uv__io_poll]: before execute


timeout 0


[uv__io_poll]: after execute


[uv__run_check]: before execute


[uv__run_check]: after execute


[uv__io_poll]: after execute


[uv__run_check]: before execute


[uv__run_check]: after execute


可以确定的是 fs 的 API 调用是在 io_poll 阶段执行的，而且我手动编译的 node 输出结果完全符合文章所说，至于在我本机通过 homebrew 或者其他方式安装的 node 的执行结果不相同，我个人的猜测是安装的 node 底层使用的 libuv 的版本不一致而对 fs 模块的调用进行了某些优化或者其他操作，导致 fs 的回调与 setImmediate 的回调不在同一个事件循环中被处理，结果展示就是 setImmediate 的输出结果比 io 要早。

个人觉得其实不必太纠结这个执行顺序，因为如果在同一个事件循环中处理所有的回调的话会是像文章中所期待的，而我们在实际编码中也不会依赖于异步回调的执行时机来编写业务逻辑。

希望能够对你有帮助

@shawncheung 感谢 v 主花了这么多时间测试代码和回复我。我仔细看了你的回复，决定不再纠结实际的输出顺序。但是我想验证下我对于 Node Event Loop 的理解是否正确，因为我英文不好，看官方文档很吃力，所以都是看了很多相关的博文来综合理解的。我描述一下我的理解，你看下我的理解是否正确：

timers > pending callbacks > idle, prepare > poll > check > close callback。分为上面这些阶段。我那段脚本主要关注 timers,poll,check 阶段。timers 和 check 很好理解，我谈下我对 poll 阶段的理解：

1. 先检查 poll 队列是否为空，如果不为空就依次执行（在这里就是输出 io ），直到清空队列。
2. 如果队列为空，再判断：
a. 如果脚本里有 setImmediate()代码，就结束 poll 阶段，进入 check 阶段（在这里就是输出 immediate ）
b. 如果脚本里没有 setImmediate()代码，就会阻塞，等待其它任务被添加进来并执行它们。如果这时又有定时器计时完成了，会重新进入 timers 阶段。（我在这里有点懵，如果既没有 setImmediate()也没有 timers 等其它任务，难道会一直阻塞在这里？那程序不是一直跑不完嘛？）

你看下我上面理解的可有偏差？

@nikolausliu 是的，基本是这样的，但是最后有一点就是如果没有定时器也没有 setImmediate 的话，系统是有一个最大等待时间的，而不会一直阻塞。

@shawncheung 理论上来说相同版本的源码，自己编译的结果跟官方编译的结果应该是相同的呀。

@dcatfly 是的，理论上应该是一样的，但是实际结果我手动编译的两个版本与本地安装的版本输出结果不同，个人猜测是使用 libuv 的版本不同，或者其他底层库的原因导致了，我最后通过修改 libuv 源码看到 fs 的回调在 io_poll 阶段执行之后就没有深究了，因为觉得纠结的价值不是很大，如果有兴趣的话你也可以试试手动编译或者使用 async_hook 这个模块来追踪一下。

@shawncheung 好的 感谢回复。