前言

好久没写博客了,因为赶着学业和打码..........鸽了好久抱歉抱歉orz
如果你比较有能力,我完全推荐你直接去看官方文档
https://nodejs.org/zh-cn/docs/guides/event-loop-timers-and-nexttick/
这里是在官方文档的基础上做的一个自己的解析与理解。

正文

事件循环操作顺序:

 ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
   └───────────────────────────┘

本文着重介绍timers（定时器） poll（轮询） check（）三个阶段

part 1.定时器阶段（timers）

取自官方:

计时器指定 可以执行所提供回调 的 阈值，而不是用户希望其执行的确切时间。在指定的一段时间间隔后， 计时器回调将被尽可能早地运
行。但是，操作系统调度或其它正在运行的回调可能会延迟它们。

注意：轮询 阶段 控制何时定时器执行。

例如，假设您调度了一个在 100 毫秒后超时的定时器，然后您的脚本开始异步读取会耗费 95 毫秒的文件:

const fs = require('fs');

function someAsyncOperation(callback) {
// Assume this takes 95ms to complete
 fs.readFile('/path/to/file', callback);
}

const timeoutScheduled = Date.now();

setTimeout(() => {
 const delay = Date.now() - timeoutScheduled;

 console.log(`${delay}ms have passed since I was scheduled`);
}, 100);

// do someAsyncOperation which takes 95 ms to complete
someAsyncOperation(() => {
const startCallback = Date.now();

 // do something that will take 10ms...
 while (Date.now() - startCallback < 10) {
   // do nothing
 }
});

当事件循环进入 轮询 阶段时，它有一个空队列（此时 fs.readFile() 尚未完成），因此它将等待剩下的毫秒数，直到达到最快的一个计时器阈值为止。当它等待 95 毫秒过后时，fs.readFile() 完成读取文件，它的那个需要 10 毫秒才能完成的回调，将被添加到 轮询 队列中并执>行。当回调完成时，队列中不再有回调，因此事件循环机制将查看最快到达阈值的计时器，然后将回到 计时器 阶段，以执行定时器的回调。在本示例中，您将看到调度计时器到它的回调被执行之间的总延迟将为 105 毫秒。
注意：为了防止 轮询 阶段饿死事件循环，libuv（实现 Node.js 事件循环和平台的所有异步行为的 C 函数库），在停止轮询以获得更多事件之前，还有一个硬性最大值（依赖于系统）。

注意到这句话:

当事件循环进入 轮询 阶段时，它有一个空队列（此时 fs.readFile() 尚未完成），因此它将等待剩下的毫秒数，直到达到最快的一个计时器阈值为止。

意味着在轮询阶段有一个阻塞的过程（同步等待意味着阻塞）
这个阻塞并非一成不变,会在轮询队列由 空 - >回调入队（这里是fs.readFile()） 时清空队列,执行回调,此时可能会延迟即将到来的timer函数

大致过程->

[                               ] 0ms
->计算阻塞时间
->等待
[ fs.readFileCallback ] 95ms 这是一个意外的事件（可能不会发生）

->readFileCallback to end 105ms
->检测到可以执行time回调了 虽然已经延迟5ms
->回到timer阶段
->执行time回调

略过了pending callback阶段,因为不影响对事件队列的理解

part 2.轮询阶段（poll）

轮询 阶段有两个重要的功能：

1. 计算应该阻塞和轮询 I/O 的时间。[1]

2. 然后，处理 轮询 队列里的事件。
   当事件循环进入 轮询 阶段且 没有被调度的计时器时 ，将发生以下两种情况之一：

如果 轮询 队列 不是空的 ，事件循环将循环访问回调队列并同步执行它们，直到队列已用尽，或者达到了与系统相关的硬性限制。[2]

如果 轮询 队列 是空的 ，还有两件事发生：

如果脚本被 setImmediate() 调度，则事件循环将结束 轮询 阶段，并继续 检查 阶段以执行那些被调度的脚本。

如果脚本 未被 setImmediate()调度，则事件循环将等待回调被添加到队列中，然后立即执行。

一旦 轮询 队列为空，事件循环将检查 已达到时间阈值的计时器。如果一个或多个计时器已准备就绪，则事件循环将绕回计时器阶段以执行这些计时器的回调。

检查阶段
此阶段允许人员在轮询阶段完成后立即执行回调。如果轮询阶段变为空闲状态，并且脚本使用 setImmediate() 后被排列在队列中，则事件循环可能继续到 检查 阶段而不是等待。

setImmediate() 实际上是一个在事件循环的单独阶段运行的特殊计时器。它使用一个 libuv API 来安排回调在 轮询 阶段完成后执行。

通常，在执行代码时，事件循环最终会命中轮询阶段，在那等待传入连接、请求等。但是，如果回调已使用 setImmediate()调度过，并且轮询阶段变为空闲状态，则它将结束此阶段，并继续到检查阶段而不是继续等待轮询事件。

注释[1]猜测和timer阶段的硬性最大值有关，此时要算出本次轮询阶段一共花费多长时间,总不能一直卡着吧！
注释[2]这里的轮询队列说的应该就是事件队列,不过除开官方文章,很多描述事件循环的文章喜欢把它叫做事件队列，这是不是一种长期的误解？

个人简述此阶段:
[1]计算轮询时间T1
[2]处理轮询队列事件
[3]判断轮询队列情况
不空->尽可能在T1内执行队列中的事件
空->等待回调被添加中,然后立即执行
空->（特殊情况）在此期间,如果被setImmediate调度,则直接进入下一阶段。

part 3.检查阶段（check）

此阶段允许人员[1]在轮询阶段完成后立即执行回调。如果轮询阶段变为空闲状态，并且脚本使用 setImmediate() 后被排列在队列中，则事件循环可能继续到检查阶段而不是等待。

setImmediate() 实际上是一个在事件循环的单独阶段运行的特殊计时器。它使用一个 libuv API 来安排回调在 轮询 阶段完成后执行。

通常，在执行代码时，事件循环最终会命中轮询阶段，在那等待传入连接、请求等。但是，如果回调已使用 setImmediate()调度过，并且轮询阶段变为空闲状态，则它将结束此阶段，并继续到检查阶段而不是继续等待轮询事件。[2]

[1]人员?说实话这里不是很懂人员的含义是指程序员吗?但查看英文文档,这里的人员就是people.有些疑惑
[2]这里指的就是上文注解中:空->（特殊情况）在此期间,如果被setImmediate调度,则直接进入下一阶段。
说实话这里的check阶段是专门为 setImmediate准备的,setImmediate为何有这么大能耐？

part 4.关闭的回调函数阶段（close callbacks）

如果套接字或处理函数突然关闭（例如 socket.destroy()），则'close' 事件将在这个阶段发出。否则它将通过 process.nextTick() 发出。

当此阶段结束，node将回到timers进行循环，也就是完成了一轮事件循环、