浏览器事件循环和Node事件循环

事件循环（Event Loop）是 JavaScript 运行时处理异步操作的核心机制。
浏览器和 Node.js 都实现了事件循环，但两者的实现方式和执行顺序存在差异。

浏览器事件循环

浏览器事件循环基于 Message Pump 实现，有宏任务和微任务两个概念。

任务类型

宏任务：

setTimeout
setInterval
DOM 事件

微任务：

Promise
MutationObserver
async/await

在执行时，同步任务优先执行，微任务在单个循环周期里遇到就会执行，宏任务每个周期只执行一次。这么设计主要是为了避免优先级高的任务被长时间阻塞。

注意：RAF（requestAnimationFrame）不是宏任务，不是 Event Loop 的任意一环，是 Render Loop 驱动。

执行顺序

浏览器事件循环的基本流程是：执行一个宏任务 → 清空所有微任务 → 渲染（可选）→ 重复

执行一个宏任务：从宏任务队列取出一个宏任务执行（首次执行时，全局 script 脚本就是一个宏任务）
- 宏任务中包含同步代码，同步代码会立即执行
- 执行过程中遇到新的宏任务（如 setTimeout），放入宏任务队列
- 执行过程中遇到微任务（如 Promise.then），放入微任务队列
清空微任务队列：当前宏任务执行完毕后，依次执行所有微任务
- 执行微任务过程中产生的新的微任务也会在当前周期执行
- 直到微任务队列完全清空
浏览器渲染（可选）：根据需求进行渲染
- 执行布局（重排），即元素宽高、位置调整
- 执行绘制（重绘）：即对元素进行上色处理，文字颜色、背景颜色绘制
- 执行合成：根据元素的层叠顺序执行合成操作
进入下个事件周期：重复步骤1，取下一个宏任务执行

浏览器渲染条件

无渲染条件，不会渲染：无 DOM 变化，不会执行渲染
同个事件循环多次修改DOM：合并成一次渲染，约 60 FPS(16.6ms)
后台标签：暂停渲染执行，不会同步屏幕，直到切回前台
密集型 JS 执行：阻塞渲染步骤，导致出现卡顿（超过 16.6ms）

执行优先级：宏任务 > 微任务 > 渲染（可选） > 下个周期

执行示例

console.log('1. 同步代码');

setTimeout(() => {
  console.log('2. 宏任务 - setTimeout');
}, 0);

Promise.resolve().then(() => {
  console.log('3. 微任务 - Promise');
});

console.log('4. 同步代码');

// 输出顺序：1 → 4 → 3 → 2
// 同步代码先执行 → 微任务执行 → 宏任务执行

注意事项

过多微任务会阻塞渲染操作
获取浏览器元素宽高，位置信息等会引起浏览器立刻执行渲染（重排 reflow）
全局 script 脚本本质就是一个宏任务
- 站在全局角度考虑，一个宏任务触发后再执行微任务
- 站在代码角度考虑，微任务队列清空后，再执行宏任务的内容。

Node.js 事件循环

Node.js 事件循环基于 libuv 实现。

image.png

timers阶段：这个阶段执行timer（setTimeout、setInterval）的回调
I/O事件回调阶段(I/O callbacks/pending callback)：执行延迟到下一个循环迭代的 I/O 回调，即上一轮循环中未被执行的一些I/O回调
闲置阶段(idle, prepare)：仅系统内部使用
轮询阶段(poll)：检索新的 I/O 事件；执行与 I/O 相关的回调（几乎所有情况下，除了关闭的回调函数，那些由计时器和 setImmediate() 调度的之外），其余情况 node 将在适当的时候在此阻塞
检查阶段(check)：setImmediate() 回调函数在这里执行
关闭事件回调阶段(close callback)：一些关闭的回调函数，如：socket.on('close', ...)

任务类型

在 Node.js 中，同样存在宏任务和微任务，与浏览器中的事件循环相似。

微任务对应有：

next tick queue：process.nextTick
other queue：Promise 的 then 回调、queueMicrotask

宏任务对应有：

timer queue：setTimeout、setInterval
I/O Callbacks Queue：延迟的 IO 事件回调
poll queue：IO事件回调
check queue：setImmediate
close queue：close事件

执行顺序

Node.js 事件循环的执行顺序为：执行一个宏任务/阶段 → 清空微任务队列（nextTick 优先）→ 进入下一个宏任务/阶段

全局代码（属于宏任务的一种，只有首次执行）
清空微任务队列：
- next tick microtask queue：process.nextTick 的微任务（优先级最高）
- other microtask queue：Promise 的 then 回调、queueMicrotask
timer queue：执行 setTimeout、setInterval 的回调
- 执行完毕后清空微任务队列
I/O callbacks queue（pending queue）：执行延迟的 I/O 回调
- 执行完毕后清空微任务队列
poll queue：检索新的 I/O 事件，执行 I/O 相关回调
- 执行完毕后清空微任务队列
check queue：执行 setImmediate 的回调
- 执行完毕后清空微任务队列
close queue：执行关闭事件的回调
- 执行完毕后清空微任务队列
重复步骤3，进入下一个事件循环

思考

1. 为什么微任务要在宏任务之后执行？

微任务的设计目的是为了在宏任务执行完毕后，立即执行一些高优先级的任务，避免被其他宏任务阻塞，保证及时响应，宏微任务的设计本身就是为任务优先级考虑。

2. 过多微任务会导致什么问题？

如果微任务队列中有大量任务，会阻塞后续的宏任务执行和浏览器渲染，导致页面卡顿。

总结

浏览器事件循环：基于 messagepump 实现，执行顺序为宏任务 → 微任务 → 渲染（可选）→ 下个周期。同步代码在宏任务内部执行，微任务在单个循环周期内会全部执行完毕，宏任务每个周期只执行一个。
Node.js 事件循环：基于 libuv 实现，分为多个阶段（timers、I/O callbacks、poll、check、close callbacks），每个阶段执行完毕后会执行微任务队列（nextTick 优先级最高），然后进入下一个阶段。
关键区别：浏览器的事件循环更简单直接，而 Node.js 的事件循环有明确的阶段划分，更适合处理 I/O 密集型任务。

浏览器事件循环和Node事件循环