Node.js 中的 Event Loop 与浏览器 Event Loop 有何不同？请详细说明其阶段 (Phases)。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Node.js 与浏览器 Event Loop：一场跨平台的“时间管理”盛宴

各位观众老爷，晚上好！我是你们的老朋友，bug 猎人小强。今天咱们不聊风花雪月，来聊聊技术圈里一个“时间管理大师”—— Event Loop。别误会，此“时间管理”非彼“时间管理”，我们说的是程序运行的调度机制，特别是 Node.js 和浏览器这两个平台上的 Event Loop。

大家可能都听说过，JavaScript 是一门单线程语言。这意味着它一次只能执行一个任务。但是，如果 JavaScript 真的只能“一条道走到黑”，那我们怎么还能进行异步操作，比如发起网络请求、处理定时器呢？难道浏览器和 Node.js 都是“假单线程”？

当然不是！秘密就在于 Event Loop。它就像一个“永动机”，不断地循环执行任务，巧妙地实现了非阻塞的异步操作。然而，Node.js 和浏览器虽然都使用了 Event Loop，但在具体实现上还是存在一些差异。今天，我们就来深入剖析这两个平台的 Event Loop，看看它们是如何“时间管理”的。

Event Loop 的基本概念

首先，我们需要明确几个基本概念：

单线程 (Single Thread): JavaScript 代码在单个线程上执行。这意味着同一时刻只能执行一个任务。
异步操作 (Asynchronous Operation): 不会立即完成的操作，例如网络请求、文件 I/O、定时器等。异步操作不会阻塞主线程，而是通过回调函数或 Promise 来处理结果。
回调函数 (Callback Function): 当异步操作完成时，会被调用的函数。
任务队列 (Task Queue) / 宏任务队列 (Macrotask Queue): 存放待执行的任务的队列。每个任务都是一个独立的单元，例如回调函数。
微任务队列 (Microtask Queue): 存放待执行的微任务的队列。微任务通常是需要在当前任务执行完成后立即执行的任务，例如 Promise 的 then 回调、MutationObserver 回调。

简单来说，Event Loop 的工作流程可以概括为以下几步：

执行栈 (Call Stack) 从上到下执行同步代码。
当遇到异步操作时，将异步任务交给对应的模块处理 (例如 Web API 或 libuv)。
异步操作完成后，将对应的回调函数放入任务队列。
Event Loop 不断地从任务队列中取出任务，放入执行栈中执行。
在当前任务执行完成后，检查微任务队列，依次执行所有微任务。
重复步骤 4 和 5，直到任务队列和微任务队列都为空。

Node.js Event Loop 的阶段 (Phases)

Node.js 的 Event Loop 基于 libuv 库实现，它将整个循环过程划分为了几个阶段，每个阶段都有特定的任务要处理。理解这些阶段对于编写高效的 Node.js 代码至关重要。

Node.js Event Loop 的阶段顺序如下：

Timers: 执行 setTimeout 和 setInterval 的回调函数。
Pending callbacks: 执行延迟到下一个循环迭代的 I/O 回调。
Idle, prepare: 仅在内部使用。
Poll: 检索新的 I/O 事件; 执行与 I/O 相关的回调（除了 timer 回调、 setImmediate()回调和 close 回调）; 在适当的时候 Node 将在这里阻塞。
Check: 执行 setImmediate() 回调。
Close callbacks: 执行一些关闭的回调函数, 例如 socket.on('close', ...)。

让我们逐个阶段进行详细分析，并结合代码示例进行说明：

1. Timers 阶段

这个阶段负责执行由 setTimeout() 和 setInterval() 调度的回调函数。但是，需要注意的是，回调函数的执行时间并非精确的。由于 Event Loop 的其他阶段可能会占用时间，实际的执行时间可能会晚于设定的延迟时间。

console.log("Start");

setTimeout(() => {
  console.log("Timeout callback");
}, 0); // 延迟 0 毫秒

console.log("End");

// 输出顺序：
// Start
// End
// Timeout callback

在这个例子中，setTimeout 的延迟时间设置为 0 毫秒。理论上，回调函数应该立即执行。但是，由于 JavaScript 是单线程的，console.log("End") 必须先执行完成，然后 Event Loop 才能进入 Timers 阶段，执行 setTimeout 的回调函数。

2. Pending callbacks 阶段

这个阶段主要处理一些操作系统层面的回调，例如 TCP 错误、某些类型的系统错误等。这些回调通常会延迟到下一个 Event Loop 迭代执行。

这个阶段的使用场景相对较少，一般情况下我们不需要直接关注它。

3. Idle, prepare 阶段

这是一个内部使用的阶段，主要用于 Node.js 内部的一些准备工作。开发者通常不需要关心这个阶段。

4. Poll 阶段

这是 Event Loop 中最重要的阶段之一。它负责：

检索新的 I/O 事件。
执行与 I/O 相关的回调函数（除了 timer 回调、 setImmediate() 回调和 close 回调）。

如果在 Poll 阶段没有新的 I/O 事件，并且也没有 setImmediate() 回调需要执行，那么 Event Loop 将会阻塞在这个阶段，等待新的 I/O 事件的到来。

const fs = require('fs');

fs.readFile('example.txt', 'utf8', (err, data) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log('File content:', data);
});

console.log('Reading file...');

// example.txt 内容: "Hello, world!"
// 可能的输出顺序：
// Reading file...
// File content: Hello, world!

在这个例子中，fs.readFile 是一个异步的 I/O 操作。当 fs.readFile 开始读取文件时，它会将回调函数放入任务队列。当文件读取完成后，Event Loop 会在 Poll 阶段执行这个回调函数。

5. Check 阶段

这个阶段专门用于执行 setImmediate() 的回调函数。

setImmediate() 的设计目的是在当前 Poll 阶段结束后立即执行回调函数。它与 setTimeout(callback, 0) 有些相似，但也有一些重要的区别。

console.log("Start");

setImmediate(() => {
  console.log("setImmediate callback");
});

setTimeout(() => {
  console.log("setTimeout callback");
}, 0);

console.log("End");

// 可能的输出顺序：
// Start
// End
// setTimeout callback
// setImmediate callback
// 或者
// Start
// End
// setImmediate callback
// setTimeout callback

在这个例子中，setImmediate 和 setTimeout 的回调函数都会在下一个 Event Loop 迭代中执行。但是，执行顺序是不确定的。这取决于 Event Loop 的具体实现以及系统环境。通常情况下，setImmediate 的回调函数会比 setTimeout 的回调函数更早执行，因为 setImmediate 会在 Check 阶段立即执行，而 setTimeout 需要等待下一个 Timers 阶段。但是，如果 setTimeout 的延迟时间设置为 0，并且在 Poll 阶段已经处理了一些 I/O 事件，那么 setTimeout 的回调函数可能会在 setImmediate 之前执行。

6. Close callbacks 阶段

这个阶段用于执行一些关闭的回调函数，例如 socket.on('close', ...)。当一个 socket 连接关闭时，会触发 close 事件，对应的回调函数会在 Close callbacks 阶段执行。

微任务 (Microtasks)

在 Node.js 和浏览器中，微任务的优先级高于宏任务。这意味着，在每个宏任务执行完成后，Event Loop 都会立即执行微任务队列中的所有微任务，然后再进入下一个宏任务的执行。

常见的微任务包括：

Promise 的 then 回调
MutationObserver 回调
process.nextTick (Node.js)

process.nextTick (Node.js)

process.nextTick 是 Node.js 中特有的一个 API，它可以将回调函数添加到微任务队列中。 process.nextTick 的回调函数会在当前操作完成后、下一个 Event Loop 迭代开始之前执行。

console.log("Start");

process.nextTick(() => {
  console.log("process.nextTick callback");
});

Promise.resolve().then(() => {
  console.log("Promise then callback");
});

console.log("End");

// 输出顺序：
// Start
// End
// process.nextTick callback
// Promise then callback

在这个例子中，process.nextTick 的回调函数和 Promise 的 then 回调函数都会在当前任务完成后立即执行。但是，process.nextTick 的优先级更高，所以它的回调函数会比 Promise 的 then 回调函数更早执行。

浏览器 Event Loop

浏览器的 Event Loop 与 Node.js 的 Event Loop 有些相似，但也有一些重要的区别。

浏览器的 Event Loop 的阶段不如 Node.js 那么明确，但可以大致概括为以下几个步骤：

执行栈从上到下执行同步代码。
当遇到异步操作时，将异步任务交给对应的模块处理 (例如 Web API)。
异步操作完成后，将对应的回调函数放入任务队列。
Event Loop 不断地从任务队列中取出任务，放入执行栈中执行。
在当前任务执行完成后，检查微任务队列，依次执行所有微任务。
更新渲染 (如果需要)。
重复步骤 4 和 5，直到任务队列和微任务队列都为空。

浏览器的任务队列主要分为两种：

宏任务队列 (Macrotask Queue): 存放宏任务，例如 setTimeout、setInterval、setImmediate (虽然名称与 Node.js 相同，但浏览器中的 setImmediate 与 Node.js 中的 setImmediate 行为不同)、I/O、用户交互事件 (例如 click、mousemove)。
微任务队列 (Microtask Queue): 存放微任务，例如 Promise 的 then 回调、MutationObserver 回调。

浏览器中的 requestAnimationFrame

requestAnimationFrame 是浏览器中一个特殊的 API，它用于在浏览器下一次重绘之前执行回调函数。 requestAnimationFrame 的回调函数会在微任务队列执行完成后、更新渲染之前执行。

console.log("Start");

requestAnimationFrame(() => {
  console.log("requestAnimationFrame callback");
});

Promise.resolve().then(() => {
  console.log("Promise then callback");
});

console.log("End");

// 可能的输出顺序：
// Start
// End
// Promise then callback
// requestAnimationFrame callback

在这个例子中，requestAnimationFrame 的回调函数会在 Promise 的 then 回调函数之后执行，因为 Promise 的 then 回调函数是一个微任务，而 requestAnimationFrame 的回调函数会在微任务队列执行完成后、更新渲染之前执行。

Node.js 与浏览器 Event Loop 的主要区别

特性	Node.js	浏览器
实现基础	libuv	HTML5 规范
阶段划分	明确的阶段划分 (Timers, Pending callbacks, Idle, prepare, Poll, Check, Close callbacks)	阶段划分不如 Node.js 那么明确，但可以大致概括为：执行栈 -> 宏任务 -> 微任务 -> 更新渲染
特有 API	`process.nextTick`	`requestAnimationFrame`
`setImmediate`	在 Check 阶段执行，设计目的是在当前 Poll 阶段结束后立即执行回调函数。	也是异步的，但是行为与 `setTimeout` 类似，会被放入宏任务队列。
应用场景	服务器端应用、命令行工具、桌面应用等。	网页应用、移动应用 (通过 WebView) 等。

总结

无论是 Node.js 还是浏览器，Event Loop 都是实现非阻塞异步操作的关键。理解 Event Loop 的工作原理，可以帮助我们编写更高效、更健壮的代码。

Node.js 的 Event Loop 基于 libuv 实现，具有更明确的阶段划分，适合处理 I/O 密集型的任务。浏览器