浏览器的 Event Loop 只分了两层优先级，一层是宏任务，一层是微任务。但是宏任务之间没有再划分优先级，微任务之间也没有再划分优先级。 而 Node.js 任务宏任务之间也是有优先级的，比如定时器 Timer 的逻辑就比 IO 的逻辑优先级高，因为涉及到时间，越早越准确；而 close 资源的处理逻辑优先级就很低，因为不 close 最多多占点内存等资源，影响不大。

Node.js 把宏任务队列拆成了五个优先级：Timers、Pending、Poll、Check、Close

• Timers Callback： 涉及到时间，肯定越早执行越准确，所以这个优先级最高很容易理解。
• Pending Callback：处理网络、IO 等异常时的回调，有的 Lniux 系统会等待发生错误的上报，所以得处理下。
• Poll Callback：处理 IO 的 data，网络的 connection，服务器主要处理的就是这个。
• Check Callback：执行 setImmediate 的回调，特点是刚执行完 IO 之后就能回调这个。
• Close Callback：关闭资源的回调，晚点执行影响也不到，优先级最低。

除了宏任务有优先级，微任务也划分了优先级，多了一个 process.nextTick 的高优先级微任务，在所有的普通微任务之前执行

Node.js 的 Event Loop 的完整流程（node11 之前）：

• Timers 阶段：执行一定数量的定时器，也就是 setTimeout、setInterval 的 callback，太多的话留到下次执行 微任务：执行所有 nextTick 的微任务，再执行其他的普通微任务
• Pending 阶段：执行一定数量的 IO 和网络的异常回调，太多的话留到下次执行 微任务：执行所有 nextTick 的微任务，再执行其他的普通微任务
• Idle/Prepare 阶段：内部用的一个阶段 微任务：执行所有 nextTick 的微任务，再执行其他的普通微任务
• Poll 阶段：执行一定数量的文件的 data 回调、网络的 connection 回调，太多的话留到下次执行。如果没有 IO 回调并且也没有 timers、check 阶段的回调要处理，就阻塞在这里等待 IO 事件 微任务：执行所有 nextTick 的微任务，再执行其他的普通微任务
• Check 阶段：执行一定数量的 setImmediate 的 callback，太多的话留到下次执行。 微任务：执行所有 nextTick 的微任务，再执行其他的普通微任务
• Close 阶段：执行一定数量的 close 事件的 callback，太多的话留到下次执行。 微任务：执行所有 nextTick 的微任务，再执行其他的普通微任务

node 11 之前是这样，node 11 之后改为了每个宏任务都执行所有微任务了