Node 中的 Event Loop 和瀏覽器中的是完全不相同的東西。

　　Node 的 Event Loop 分為 6 個階段，它們會按照順序反復運行。每當進入某一個階段的時候，都會從對應的回調隊列中取出函數去執行。當隊列為空或者執行的回調函數數量到達系統設定的閾值，就會進入下一階段。

　　(1)Timers(計時器階段)：初次進入事件循環，會從計時器階段開始。此階段會判斷是否存在過期的計時器回調(包含 setTimeout 和 setInterval)，如果存在則會執行所有過期的計時器回調，執行完畢后，如果回調中觸發了相應的微任務，會接著執行所有微任務，執行完微任務后再進入 Pending callbacks 階段。

　　(2)Pending callbacks：執行推遲到下一個循環迭代的I / O回調(系統調用相關的回調)。

　　(3)Idle/Prepare：僅供內部使用。

　　(4)Poll(輪詢階段)：

　　當回調隊列不為空時：會執行回調，若回調中觸發了相應的微任務，這里的微任務執行時機和其他地方有所不同，不會等到所有回調執行完畢后才執行，而是針對每一個回調執行完畢后，就執行相應微任務。執行完所有的回調后，變為下面的情況。

　　當回調隊列為空時(沒有回調或所有回調執行完畢)：但如果存在有計時器(setTimeout、setInterval和setImmediate)沒有執行，會結束輪詢階段，進入 Check 階段。否則會阻塞并等待任何正在執行的I/O操作完成，并馬上執行相應的回調，直到所有回調執行完畢。

　　(5)Check(查詢階段)：會檢查是否存在 setImmediate 相關的回調，如果存在則執行所有回調，執行完畢后，如果回調中觸發了相應的微任務，會接著執行所有微任務，執行完微任務后再進入 Close callbacks 階段。

　　(6)Close callbacks：執行一些關閉回調，比如socket.on('close', ...)等。

　　下面來看一個例子，首先在有些情況下，定時器的執行順序其實是隨機的

　　對于以上代碼來說，setTimeout 可能執行在前，也可能執行在后首先 setTimeout(fn, 0) === setTimeout(fn, 1)，這是由源碼決定的進入事件循環也是需要成本的，如果在準備時候花費了大于 1ms 的時間，那么在 timer 階段就會直接執行 setTimeout 回調那么如果準備時間花費小于 1ms，那么就是 setImmediate 回調先執行了當然在某些情況下，他們的執行順序一定是固定的，比如以下代碼：

　　在上述代碼中，setImmediate 永遠先執行。因為兩個代碼寫在 IO 回調中，IO 回調是在 poll 階段執行，當回調執行完畢后隊列為空，發現存在 setImmediate 回調，所以就直接跳轉到 check 階段去執行回調了。

　　上面都是 macrotask 的執行情況，對于 microtask 來說，它會在以上每個階段完成前清空 microtask 隊列，下圖中的 Tick 就代表了 microtask

　　對于以上代碼來說，其實和瀏覽器中的輸出是一樣的，microtask 永遠執行在 macrotask 前面。最后來看 Node 中的 process.nextTick，這個函數其實是獨立于 Event Loop 之外的，它有一個自己的隊列，當每個階段完成后，如果存在 nextTick 隊列，就會清空隊列中的所有回調函數，并且優先于其他 microtask 執行。

　　對于以上代碼，永遠都是先把 nextTick 全部打印出來。