Event Loop 严格按六个阶段轮转，Timer 阶段执行已过期的 setTimeout/setInterval 回调，Check 阶段执行 setImmediate 回调，二者顺序由阶段位置决定，且各阶段后均清空微任务队列。

Node.js 中的 Event Loop 并不是简单按“谁先注册谁先执行”来排代码顺序，而是严格按六个阶段的轮转节奏推进。Timer 阶段和 Check 阶段的执行次序，取决于它们在事件循环中所处的位置、任务是否已就绪，以及当前 poll 阶段是否阻塞或空闲。

Timer 阶段只处理真正过期的定时器

Timer 阶段对应 setTimeout 和 setInterval 的回调，但它不会在设定时间一到就立刻执行——而是等到事件循环进入该阶段时，才检查哪些定时器已真正过期（即 当前时间 - idleStart ≥ idleTimeout）。即使你写了 setTimeout(fn, 0)，它也得等下一轮循环到达 Timer 阶段才能被取出执行。

• 如果多个定时器同时过期，按注册顺序先进先出执行
• 如果 Timer 队列为空，事件循环直接跳过该阶段
• 即使设了 0ms，实际执行仍可能延迟几毫秒，受系统调度影响

Check 阶段紧接在 Poll 阶段之后

setImmediate() 的回调统一放在 Check 阶段执行，而这个阶段总是在 Poll 阶段完成之后才触发。关键点在于：Poll 阶段的行为会直接影响 Check 是否能“马上”运行。

Rydberg Agent Node

使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r

下载

• Poll 队列不为空 → 先清空所有 I/O 回调，再进 Check 阶段
• Poll 队列为空，且没待处理的 I/O → 若有 setImmediate，立即进 Check；否则可能等待新事件或直接跳到下一循环
• 如果 poll 阶段因 I/O 操作阻塞（比如读大文件），Check 就得等它结束才能开始

Timer 和 Check 的相对优先级由循环位置决定

事件循环固定顺序是：Timer → Pending callbacks → Idle/Prepare → Poll → Check → Close callbacks。这意味着：

立即学习“Java免费学习笔记（深入）”；

• 同一轮循环中，Timer 总比 Check 先执行（哪怕 setTimeout(0) 和 setImmediate() 在同一行代码里）
• 但跨轮循环时，情况可能反转：比如 setTimeout(0) 在本轮未触发（因未到 Timer 阶段），而 setImmediate() 已在本轮 Check 阶段执行了
• 常见陷阱：在 I/O 回调（如 fs.readFile）里同时调用 setTimeout(0) 和 setImmediate()，往往后者先输出——因为此时刚退出 Poll，立刻进 Check；而 setTimeout(0) 得等下一轮 Timer 阶段

微任务会插在阶段切换之间

虽然 Timer 和 Check 都是宏任务，但它们各自执行完后，都会立刻清空当前微任务队列（包括 Promise.then、process.nextTick）。所以：

• Timer 阶段执行完一个 setTimeout 回调 → 立即执行所有已排队的 microtask
• Check 阶段执行完一个 setImmediate 回调 → 同样立刻处理 microtask
• 这会导致看似“同步”的嵌套行为，比如在 setTimeout 回调里 new Promise(...)，其 then 一定在该 setTimeout 之后、但早于下一个宏任务