一、poll阶段在六个阶段中的位置
Node.js的事件循环由libuv实现，按顺序经过timers、pendingcallbacks、idle/prepare、poll、check、closecallbacks六个阶段。poll阶段排在第四位，前面是仅供内部使用的idle/prepare，后面是执行setImmediate回调的check阶段。
poll阶段承担两项工作：计算本次阻塞等待I/O的时长，以及执行poll队列中已就绪的I/O回调。官方文档对进入poll阶段时的状态给出了分支判断：如果poll队列非空，同步执行队列中的回调直到清空或达到系统相关的硬性上限；如果队列为空，则根据是否有setImmediate调度和timer到期情况决定等待策略。libuv设有硬性上限防止poll阶段饿死事件循环，这一点在官方文档中有明确说明。
这里容易产生一个理解偏差：poll阶段“等待”的是事件通知机制（Linux的epoll、macOS的kqueue、Windows的IOCP）返回的新I/O事件，而不是在回调执行过程中反复检查超时。StackOverflow上对libuv行为的澄清指出，poll超时限制的是等待新事件的时间，不是poll队列回调的总执行时间；libuv没有机制在回调执行超时后将其移入pending队列。
二、poll超时的计算逻辑
poll阶段在阻塞前需要确定一个等待时长。这个时长的计算依赖三个因素：最近的timer何时到期、是否存在setImmediate调度、以及当前是否有活跃的handle或request。
如果存在即将到期的timer，poll的阻塞时长被限制在到该timer阈值的剩余毫秒数内。官方文档给出的例子是：fs.readFile的回调在poll阶段等待了95毫秒后完成，执行耗时10毫秒，然后事件循环发现最近的timer阈值已到，回绕到timers阶段执行timer回调。从timer被调度到回调执行，总延迟为105毫秒。
如果poll队列为空且存在setImmediate调度，poll阶段不会等待，直接结束并进入check阶段执行setImmediate回调。如果没有timer也没有setImmediate，poll阶段会阻塞等待新的I/O事件，直到有事件到达或达到系统相关的上限。这个上限在不同平台上的具体数值不同，作用是防止事件循环在poll阶段停留过久。
三、setImmediate与setTimeout在poll前后的行为差异
这两个函数的执行时机差异是poll阶段行为中最常被讨论的部分。官方文档的表述是：setImmediate设计为在当前poll阶段完成后执行；setTimeout安排在经过最小毫秒阈值后运行。
在主模块中同时调用setTimeout(fn,0)和setImmediate(fn)，两者的执行顺序不确定。这是因为进入事件循环时，进程的性能状态决定了timer是否已经到期。如果timer尚未到期，poll阶段可能先阻塞或直接进入check阶段执行setImmediate；如果timer恰好到期，timers阶段会先执行。
在I/O回调内部调用这两个函数时，setImmediate总是先执行。原因是I/O回调在poll阶段执行，回调完成后poll队列清空，事件循环检查到setImmediate调度，直接进入check阶段，不需要等待timer阈值。这一行为差异的实践含义是：如果你需要在I/O操作完成后尽快执行某段逻辑，setImmediate比setTimeout(fn,0)更可预测。
四、微任务对poll阶段的绕过
process.nextTick和Promise回调不在事件循环的任何阶段中执行。官方文档明确指出process.nextTick不属于事件循环的一部分，nextTickQueue在当前操作完成后被处理，不受当前所处阶段的限制。
这意味着在poll阶段执行I/O回调时，如果回调内部调用了process.nextTick，这些回调会在当前I/O回调结束后、poll队列继续处理之前被清空。递归调用process.nextTick会阻止事件循环进入poll阶段，造成I/O饥饿。Promise的微任务队列在nextTickQueue之后清空，同样优先于poll队列中的下一个I/O回调。
一个在排查延迟问题时形成的习惯：当setTimeout回调的实际执行时间明显晚于设定值时，先检查同步代码块中是否存在递归nextTick或长链Promise。这两者都会推迟事件循环到达poll阶段的时间，进而推迟所有依赖poll阶段处理的I/O回调。
五、文件系统操作与poll阶段的实际关系
fs.readFile的回调在poll阶段执行，但文件的实际读取发生在libuv的线程池中。线程池默认大小为4（通过UV_THREADPOOL_SIZE环境变量调整），文件系统操作、DNS解析（dns.lookup）、部分加密操作共享这个池子。
一个容易忽略的后果是：当大量fs.readFile并发调用时，线程池中的排队延迟会表现为poll阶段回调的延迟。回调确实在poll阶段执行，但它在poll队列中等待的时间取决于线程池何时完成读取。如果线程池被一个慢速操作占满，后续的文件读取回调都无法及时进入poll队列。
dns.lookup与dns.resolve的区别在此处有实际意义。dns.lookup使用线程池，受线程池饱和影响；dns.resolve通过非阻塞网络socket完成，不占用线程池。在需要高并发DNS查询的场景中，这个差异会影响poll阶段处理网络I/O的效率。
六、监控poll阶段被阻塞的程度
perf_hooks模块提供了monitorEventLoopDelay，测量的是libuv触发高精度定时器相对于计划时间的延迟。这个指标能反映事件循环被同步代码或微任务链阻塞的程度。如果p99值持续偏高，说明poll阶段的进入被推迟，或者poll阶段内的回调执行时间过长。
另一个指标是performance.eventLoopUtilization()，返回事件循环在epoll_wait（或对应系统调用）之外花费的时间比例。持续高于0.8意味着事件循环大部分时间在执行业务代码而非等待I/O，这是考虑将CPU密集任务移入worker_threads的信号之一。
这两个API不能直接告诉你“poll阶段阻塞了多久”，但结合起来可以判断延迟来源是同步代码、微任务链、还是线程池排队。在实践中，先看monitorEventLoopDelay的p99确认存在延迟，再看eventLoopUtilization区分是CPU占用还是I/O等待问题。
七、练习与思考
练习1：编写一个脚本，在fs.readFile的回调中分别调用setImmediate和setTimeout(fn,0)，记录两者输出的顺序。然后在主模块中做同样的调用，对比顺序差异。用poll阶段与check阶段的协作关系解释结果。
练习2：设置UV_THREADPOOL_SIZE=1，并发发起10个fs.readFile读取同一文件，在回调中记录时间戳。观察回调到达的间隔模式，并解释线程池排队与poll队列处理之间的关系。
思考：poll阶段的硬性上限（防止饿死事件循环）在不同操作系统上的具体数值不同。如果一段代码在Linux上运行正常，部署到Windows后出现I/O回调延迟增加，你会优先检查哪些因素？
八、延伸阅读与参考文献
Node.js官方文档“TheNode.jsEventLoop,Timers,andprocess.nextTick()”。poll阶段的进入条件、超时计算、setImmediate与setTimeout的上下文依赖行为均有明确说明，是理解该阶段的第一手材料。https://nodejs.org/learn/asynchronous-work/event-loop-timers-and-nexttick
libuv官方文档“Designoverview”。事件循环各阶段的执行顺序、poll超时的计算规则、以及平台I/O机制的选用，是Node.js官方文档背后的底层依据。https://docs.libuv.org/en/v1.x/design.html
StackOverflow“Howdopollandpendingphasesworkinlibuv?”。对poll超时语义的澄清：限制的是等待新事件的时间，不是poll队列回调的执行时间，libuv没有基于回调执行时长的移队机制。https://stackoverflow.com/questions/77076616/
GitHubsujeet-pro/sujeet.pro事件循环文章。记录了libuv线程池的使用范围（文件系统、dns.lookup、异步加密、zlib），以及monitorEventLoopDelay和eventLoopUtilization的适用场景区分。https://github.com/sujeet-pro/sujeet.pro/blob/main/content/articles/nodejs-event-loop/README.md
