node.js事件循环基于libuv，划分为timers、pending callbacks、poll、check、close callbacks等六阶段；process.nexttick优先于promise微任务；无ui渲染，不支持requestanimationframe；fs等操作依赖libuv线程池。
Node.js 事件循环基于 libuv，阶段划分更细
Node.js 不直接复用浏览器的事件循环模型，而是通过 C 语言库 libuv 实现自己的调度机制。它把整个循环拆成六个明确阶段：timers → pending callbacks → poll → check → close callbacks（还有 idle/prepare，但通常不参与任务调度）。每个阶段只处理对应类型的任务，比如 setTimeout 和 setInterval 只在 timers 阶段 执行，setImmediate 在 check 阶段，而 I/O 回调集中在 poll 阶段。这种分阶段设计让服务器能更精准地控制 I/O 调度顺序和吞吐量。
微任务优先级规则不同：process.nextTick 优先于 Promise
在 Node.js 中，process.nextTick() 的回调属于“伪微任务”，它比所有 Promise.then、queueMicrotask 等标准微任务执行得更早——甚至在当前操作刚结束、还没进入下一事件循环阶段时就触发。这意味着：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
process.nextTick会插在当前宏任务末尾、任何微任务之前 - 连续调用多次
nextTick，它们会全部执行完，才轮到 Promise 回调 - 滥用
nextTick容易导致 I/O 饥饿，比如阻塞 poll 阶段读取新连接
没有 UI 渲染环节，也不支持 requestAnimationFrame
浏览器事件循环必须配合渲染管线，所以在每轮宏任务执行完、微任务清空后，会插入一次 UI 渲染（样式计算、布局、绘制）。而 Node.js 没有 DOM 和界面，自然没有渲染阶段，也不会触发 requestAnimationFrame。同时，Node.js 提供了 setImmediate 作为替代方案，用于在当前 poll 阶段结束后、下一轮 timers 开始前执行回调，适合做“下一个滴答”的轻量调度。
异步 I/O 依赖线程池，部分操作非纯事件驱动
浏览器中大多数异步操作（如 fetch、定时器、用户事件）由系统级线程（网络线程、定时器线程等）完成，回调直接进 JS 任务队列。Node.js 则不同：它用 默认 4 线程的 libuv 线程池 处理不支持原生异步的操作，比如 fs.readFile（文件读取）、dns.lookup、crypto.pbkdf2。这些任务不是靠 epoll/kqueue 触发，而是在线程池中同步执行后，再把结果推回事件循环。这也意味着，大量 CPU 密集型或阻塞式文件操作可能耗尽线程池，拖慢整体响应。
