翻译了一个关于 Node.js 事件循环很棒的系列文章，共 5 篇（Nodejs）
翻译了一个关于 Node.js 事件循环很棒的系列文章，共 5 篇（Nodejs）
https://github.com/zhangxiang958/zhangxiang958.github.io/issues/43 事件循环总览
https://github.com/zhangxiang958/zhangxiang958.github.io/issues/44 setTimeout, setImmediate, nextTick
https://github.com/zhangxiang958/zhangxiang958.github.io/issues/45 promises,nexttick 与 immediate
https://github.com/zhangxiang958/zhangxiang958.github.io/issues/46 IO 处理
https://github.com/zhangxiang958/zhangxiang958.github.io/issues/47 最佳实践
不好意思，回复晚了。
说实话，我一开始看到你的问题也有点愣，我在我的电脑 (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 要早。
个人觉得其实不必太纠结这个执行顺序，因为如果在同一个事件循环中处理所有的回调的话会是像文章中所期待的，而我们在实际编码中也不会依赖于异步回调的执行时机来编写业务逻辑。
希望能够对你有帮助
感谢 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 等其它任务，难道会一直阻塞在这里？那程序不是一直跑不完嘛？）
你看下我上面理解的可有偏差？
是的，理论上应该是一样的，但是实际结果我手动编译的两个版本与本地安装的版本输出结果不同，个人猜测是使用 libuv 的版本不同，或者其他底层库的原因导致了，我最后通过修改 libuv 源码看到 fs 的回调在 io_poll 阶段执行之后就没有深究了，因为觉得纠结的价值不是很大，如果有兴趣的话你也可以试试手动编译或者使用 async_hook 这个模块来追踪一下。
非常棒，翻译关于 Node.js 事件循环的系列文章对社区来说是个巨大的贡献！Node.js 的事件循环是其非阻塞、异步 I/O 模型的核心，理解它对于掌握 Node.js 的高性能和并发处理至关重要。
以下是一个简短的代码示例，用于展示 Node.js 事件循环的基本工作原理。这个示例演示了如何使用 setTimeout 和 setImmediate 来理解事件循环的不同阶段：
console.log('Start');
setTimeout(() => {
console.log('Timeout');
}, 0);
setImmediate(() => {
console.log('Immediate');
});
process.nextTick(() => {
console.log('Next Tick');
});
console.log('End');
输出顺序将是：
Start
End
Next Tick
Immediate
Timeout
这个顺序展示了 Node.js 事件循环的处理顺序：
console.log('Start')和console.log('End')是同步代码，立即执行。process.nextTick()回调会在当前操作完成后尽快执行，因此它在Immediate和Timeout之前运行。setImmediate()回调在 I/O 事件回调之后执行，因此在Timeout之前。setTimeout()回调最后执行，因为它被放入了计时器队列中，等待事件循环的下一个计时器阶段。
希望这个示例能帮助读者更好地理解 Node.js 事件循环的工作原理。你的翻译工作将帮助更多人深入理解这一关键概念，非常感谢！
