浏览器每次宏任务后严格清空微任务队列并插入渲染，node.js则按6阶段循环，process.nexttick作为阶段切换钩子优先于promise执行，且无渲染环节。
在浏览器控制台和 Node.js REPL 中输入同一段含异步逻辑的代码，输出顺序常常不一致——这不是 bug，而是底层事件循环模型差异导致的微观行为分化。关键不在“有没有微任务”，而在于“谁先跑、跑几次、何时让出控制权”。
微任务队列是否被“清空”
浏览器每次执行完一个宏任务后，会严格清空整个微任务队列：包括本轮新产生的 Promise.then、queueMicrotask，甚至嵌套触发的微任务，全部执行完毕才进入渲染或下一个宏任务。
Node.js REPL（尤其 v12+）已趋近浏览器语义，但仍有微妙差别：
- v10 及以前：I/O 回调内触发的微任务，只执行“第一批可立即运行”的，可能跳过后续新增项
- v11–v12：改为“阶段切换前清空”，更接近浏览器，但若在 poll 阶段中途插入大量 nextTick，仍可能打断 I/O 处理节奏
- REPL 是交互式环境，每行代码默认被包裹为独立 script 宏任务，但内部微任务调度仍受 libuv 阶段约束
process.nextTick 的“插队特权”仅存在于 Node
浏览器没有 process.nextTick。它在 Node 中不是标准微任务，而是阶段切换钩子：每次从一个事件循环阶段（如 timers → poll）跳转前，强制执行所有 pending 的 nextTick 回调，且优先级高于 Promise.then。
例如：
console.log('a');
Promise.resolve().then(() => console.log('b'));
process.nextTick(() => console.log('c'));
在 Node REPL 输出是 a → c → b；在浏览器控制台则报错 process is not defined，或若用 queueMicrotask 替代，则输出 a → b → c（因同属微任务，无优先级差）。
setTimeout(fn, 0) 在 REPL 中可能“延迟一拍”
浏览器中 setTimeout(fn, 0) 总是排在下一轮宏任务最开头，行为稳定。
Node REPL 中，它归属 timers 阶段，但实际执行时机取决于当前所处阶段：
- 若刚从 poll 阶段退出（比如用户敲回车触发 REPL 读取），timers 阶段可能被跳过，先走 check 阶段 → setImmediate 先于 setTimeout 执行
- 若 timers 阶段就绪且无阻塞，setTimeout 才能准时触发
- REPL 每次输入都是一次新的宏任务，但定时器计时器共享全局状态，容易出现“看似随机”的交错
UI 渲染环节彻底缺席于 REPL
浏览器宏任务后固定穿插 UI 渲染步骤（即使没 DOM 变更，也会触发重排重绘检查），这会人为制造一个“不可插入”的间隙——微任务总在渲染前执行完毕，开发者能感知到视觉反馈的边界。
Node REPL 没有 GUI 线程，也不存在渲染阶段。宏任务执行完直接切微任务，再进下一宏任务，节奏更紧凑、更“不可见”。这也意味着，在 REPL 中观察到的“快”，其实是省略了浏览器必须做的同步开销，而非 Node 本身更快。
