event loop 是运行环境实现的异步调度模型，浏览器采用“宏任务→微任务→渲染”单线性循环，node.js 基于 libuv 分六阶段轮转；微任务执行时机、nexttick/setimmediate 机制及渲染环节存在本质差异。
Event Loop 不是 JavaScript 语言标准定义的机制，而是运行环境（浏览器或 Node.js）为协调异步操作而实现的调度模型。它本质不是“一套代码跑哪儿都一样”，而是同一套 JS 语法，在不同底层系统上被不同方式调度——浏览器重 UI 响应与渲染节奏，Node.js 重 I/O 效率与系统资源调度。
结构上：单线性循环 vs 阶段式轮转
浏览器 Event Loop 是“宏任务 → 清空微任务 → 渲染 → 下一轮宏任务”的固定链条，每轮只处理一个宏任务，之后必须执行完所有已排队微任务，再触发页面重绘。
Node.js 的 Event Loop 基于 libuv，划分为 6 个明确阶段：timers → pending callbacks → poll → check → close callbacks。每个阶段只处理自己队列里的回调，比如 poll 阶段专注执行 I/O 完成后的回调，setImmediate 则一定在 poll 之后、close 之前执行。
这意味着：
- setTimeout(0) 属于 timers 阶段，但若 poll 阶段正忙于处理大量文件读取，它可能被延迟几毫秒才真正执行
- fs.readFile 回调在 poll 阶段执行，其内部 Promise.then 不会立刻全部跑完，而是等该阶段结束、进入下一阶段前才检查微任务
- 没有“每宏任务后必清空微任务”的强保证，尤其在高 I/O 密度场景下
微任务执行时机不统一
浏览器中，只要同步代码结束，就立即、彻底地执行当前所有微任务（包括新 Promise 产生的嵌套微任务），形成确定的原子性更新。
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
Node.js 中微任务只在阶段切换前检查并执行，且行为随版本演进：
- v10 及以前：I/O 回调结束后清空全部微任务（接近浏览器）
- v11 起：只执行当前可运行的微任务，不递归清空新产生的；后续微任务可能卡到 check 或 timers 阶段切换时
- v12+ 虽恢复部分清空语义，但 poll 阶段密集 I/O 仍可能导致 Promise 链被截断
所以一段 Promise.resolve().then(() => console.log(1)).then(() => console.log(2)) 在浏览器里总输出 1→2；在 Node.js 的 fs 回调里，可能只输出 1，2 要等到下一轮 check 阶段才执行。
Node.js 独有调度杠杆：nextTick 和 setImmediate
这两个 API 浏览器根本没有，却是 Node.js 精细控制时序的关键：
- process.nextTick 不是微任务，也不是宏任务。它在每个阶段即将退出时强制插入，优先级高于 Promise.then，甚至高于当前阶段剩余的其他回调
- setImmediate 属于 check 阶段，在 poll 阶段结束后立即执行，因此常比 setTimeout(0) 更早——前提是 poll 阶段没被阻塞
- 当 poll 阶段空闲时，setTimeout(0) 和 setImmediate 执行顺序不确定；但一旦 poll 阶段有 I/O 回调，setImmediate 几乎总先于 setTimeout(0)
渲染环节是浏览器独有硬约束
浏览器每次宏任务 + 微任务执行完毕后，必须进行一次渲染（样式计算、布局、绘制），这是用户可见反馈的基础。这个步骤在 Node.js 中完全不存在。
这也导致实际开发中一个关键区别：
- Vue 的 nextTick、React 的 flushSync，底层依赖的是浏览器 microtask 队列的可预测性，它们在 Node.js 环境（如 SSR）中需降级为 setImmediate 或 setTimeout 模拟
- 用 requestAnimationFrame 控制动画帧，在 Node.js 里根本不可用，因为没有渲染管线
- MutationObserver 只存在于浏览器，用于监听 DOM 变化；Node.js 无 DOM，自然也不支持
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
