浏览器和Node.js事件循环本质不同：浏览器采用“宏任务→微任务→渲染”线性模型，无明确阶段；Node.js基于libuv分为timers、poll等6个严格阶段，且process.nextTick优先级高于所有微任务。
浏览器和 Node.js 的事件循环，表面看都是“先宏后微”，但底层逻辑、阶段划分和任务调度优先级完全不同。直接套用一方经验到另一方，很容易踩坑。
执行结构：两套完全不同的阶段模型
浏览器事件循环没有明确的“阶段”概念，它按“宏任务 → 清空微任务 → 可能渲染 → 下一个宏任务”线性推进。而 Node.js 基于 libuv，严格划分为 6 个阶段：timers、pending callbacks、idle/prepare、poll、check、close callbacks。每个阶段只处理对应队列里的任务，且顺序固定。
- setTimeout 回调在浏览器中属于宏任务，在 Node 中落在 timers 阶段；但如果 poll 阶段阻塞（比如有持续 I/O），timers 阶段可能被推迟执行
- setImmediate 只存在于 Node，在 check 阶段运行，总在 poll 阶段之后、close 之前，与 setTimeout(0) 并不等价
- 浏览器没有 check 阶段，也没有 setImmediate，它的 UI 渲染是隐式环节，发生在微任务清空后、下一个宏任务前
微任务执行时机：看似一致，实则埋雷
两者都保证“每个宏任务结束后立即执行全部微任务”，但 Node.js 多了一个更高优先级的机制：process.nextTick。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- process.nextTick 不属于任何事件循环阶段，它在当前操作完成、进入下一阶段前立刻执行
- 它的优先级高于 Promise.then、queueMicrotask 等所有微任务，甚至能在一次微任务清空中插队多次
- 浏览器中没有 process.nextTick，所以类似逻辑若迁移到浏览器，必须改用 queueMicrotask 或 Promise.resolve().then()
任务语义错位：同名 API，不同调度位置
很多异步 API 名字一样，行为却因环境而异，这是最容易引发 bug 的地方。
- setTimeout(fn, 0) 在浏览器中基本等于“下一轮宏任务开始时”；在 Node 中虽属 timers 阶段，但若前一阶段耗时长（如大量文件读取卡在 poll），实际延迟可能远超 0ms
- MutationObserver 是浏览器专属，用于监听 DOM 变化；Node 没有 DOM，自然不支持
- requestAnimationFrame 浏览器专用，与帧率同步；Node 中无此概念，也不提供替代 API
设计目标驱动差异：UI 响应 vs I/O 吞吐
浏览器事件循环必须为渲染让路，主线程执行 JS 时 GUI 渲染线程会被挂起；Node.js 没有界面，所有资源都倾斜给 I/O 效率。
- 浏览器每轮循环后会主动检查是否需要重绘，确保动画、滚动、交互流畅
- Node 的 poll 阶段会尽可能多地执行 I/O 回调，甚至可能连续执行多个而不退出，以减少上下文切换开销
- 这种差异意味着：同样一段含大量 Promise 链的代码，在浏览器中可能影响页面响应，在 Node 中却可能提升吞吐量
