node.js定时器阶段仅负责到期检查，不阻塞执行；其执行受轮询阶段阻塞、setimmediate跳过及nexttick插队影响，且各阶段后立即清空微任务队列。
Node.js定时器阶段（Timers Phase）不是孤立运行的，它与后续阶段存在明确的协作与制约关系。理解这些交互规则，才能准确预判异步任务的实际执行顺序和延迟原因。
定时器阶段只负责“到期检查”，不阻塞也不等待
该阶段会扫描最小堆中堆顶的定时器，只要其设定时间 ≤ 当前运行时间，就立即执行回调；一旦队列清空，或单次执行达到上限（如V8限制），事件循环立刻进入待定回调阶段（Pending Callbacks），不会停留等待其他未到期定时器。这意味着：即使设置了 setTimeout(fn, 1) 和 setTimeout(fn, 100)，前者到期后执行，后者仍需等到下一轮循环的 timers 阶段才可能被检查。
轮询阶段（Poll）直接影响定时器能否及时执行
如果 poll 阶段有大量 I/O 回调待处理，或者正在等待新 I/O 事件（如空队列时阻塞等待），事件循环就会卡在该阶段，无法及时回到 timers 阶段。此时即使定时器已到期，也要等 poll 阶段退出后才能执行。常见于：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 高频文件读写、数据库查询回调堆积
- HTTP 服务持续接收请求但响应逻辑较重
- 使用
fs.readFileSync等同步 I/O 阻塞主线程（间接拉长 poll 前置准备）
setImmediate 和 nextTick 不参与 timers 阶段，但会改变整体节奏
process.nextTick() 在当前操作结束后立即执行，优先级高于所有阶段；setImmediate() 则排在 poll 阶段之后、check 阶段执行。关键影响在于：
- 若 poll 队列为空且存在 setImmediate 回调，事件循环会跳过 timers 直接进入 check 阶段——导致
setTimeout(fn, 0)被延后到下一轮 - 在 I/O 回调内部调用两者时，setImmediate 几乎总比 setTimeout(0) 先执行，因为此时 poll 阶段即将结束
- nextTick 回调会在任何阶段结束前清空，因此它能“插队”进 timers 阶段执行之后、但仍在同一轮循环内
微任务清空机制覆盖所有阶段边界
每个阶段结束后（包括 timers、poll、check 等），Node.js 都会立即清空当前轮次的微任务队列（Promise.then/catch、queueMicrotask）。这意味着：
- 即使 timers 阶段执行了多个
setTimeout回调，它们之间的 Promise 链也不会被中断 - 一个
setTimeout回调里抛出的 Promise 错误，其 catch 会紧随该回调之后执行，而不是等到下个阶段 - 微任务不会跨轮次累积，但宏任务（如 setTimeout）会排队到对应阶段，受整体循环节奏制约
