浏览器事件循环和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 实现。
- 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 密集型任务。
参考内容
- Event Loop - MDN
- The Node.js Event Loop - Node.js 官方文档