轮询阶段是node.JS事件循环的核心，负责处理绝大多数i/o回调，确保高性能和非阻塞特性。1. 它首先检查timers和pending callbacks队列，优先处理其中的回调。2. 然后执行poll队列中的i/o回调，直到队列为空或达到内部限制。3. 若poll队列为空，会检查setimmediate队列，若有则跳到check阶段执行。4. 若setimmediate队列也为空，则检查timers队列，等待最近定时器到期或新i/o事件。5. 若所有队列均空且无定时器，事件循环将完全阻塞，等待i/o事件唤醒。开发者应避免长时间同步操作，合理使用setimmediate和promise，理解其执行优先级，以优化性能并精准控制异步任务时机。
事件循环中的“轮询”阶段，简单来说，就是Node.js（或者说，异步I/O模型）处理绝大多数I/O回调的地方。它像是整个事件循环的心脏，负责检查是否有新的I/O事件完成，比如文件读取完毕、网络请求收到响应等等。当事件循环进入这个阶段时，它会去查看那些已经完成的、等待被执行的I/O操作回调函数，并把它们拿出来执行。如果暂时没有I/O事件完成，它就会在这里“等待”一会儿，直到有新的事件到来或者有其他阶段的计时器到期。
解决方案
在我看来，理解轮询阶段是深入Node.js异步编程的关键一步。它不仅仅是一个技术名词，更是Node.js高性能、非阻塞特性的核心体现。当Node.js的事件循环进入轮询阶段时，它会做几件重要的事情。
它会检查是否有timers（定时器，如setTimeout、setInterval）的回调函数已经准备好执行了，或者pending callbacks（系统操作的回调，如TCP错误）队列里有没有待处理的。如果这些队列里有东西，它会优先处理它们。
处理完这些后，真正的“轮询”就开始了。它会查看poll队列。这个队列里存放的是几乎所有I/O操作完成后的回调，比如数据库查询结果返回、http请求响应到达、文件读取完成等等。Node.js会尽可能地执行这些队列里的回调，直到队列为空或者达到某个内部限制。
一个非常重要的决策点就在这里：如果poll队列为空了，Node.js不会傻傻地一直等着。它会检查setImmediate队列里是否有待执行的回调。如果有，它会立即跳到check阶段去执行它们，而不是继续等待I/O。但如果setImmediate队列也空了，它会再看看timers队列里有没有即将到期的定时器。如果有，它就会计算出最近一个定时器到期的时间，然后在这里“阻塞”一段时间，等待新的I/O事件或者等待定时器到期。
如果所有队列都空了，并且也没有即将到期的定时器，那么事件循环就会在这里真正地“挂起”，等待任何新的I/O事件发生。这正是“轮询”这个词的精髓所在——它不是被动地等待，而是在一个活跃的循环中，不断地检查和等待。当然，process.nextTick和Promise的微任务队列则是在每个阶段之间、在当前操作执行完毕后立即清空，这使得它们具有更高的优先级。
轮询阶段与其他事件循环阶段有何关联？
轮询阶段就像是事件循环的“主战场”，或者说，是Node.js大部分工作发生的地方。它位于pending callbacks阶段之后，check阶段（setImmediate的回调）和close callbacks（socket.on(‘close’)等）阶段之前。这种顺序设计是Node.js能够高效处理I/O的关键。
你可以把事件循环想象成一个无限循环的列车，每个“阶段”就是列车的一个站点。列车从timers站出发，经过pending callbacks站，然后到达poll站。在poll站，列车可能会停留最长时间，等待乘客（I/O事件）上车。如果poll站没乘客了，它会快速检查下一个check站（setImmediate），看看那里有没有人等着。如果没有，它会再次看看timers站有没有新乘客（新的定时器）快要到了，决定是继续等待还是直接开往下一圈。
这种关联性意味着，一个I/O操作的回调，比如一个数据库查询的结果，它最终会在poll阶段被执行。而如果你用setImmediate来延迟一个任务，它会在当前poll阶段处理完大部分I/O后，在下一个check阶段被执行。这种精妙的协作，确保了Node.js在单线程模型下依然能保持非阻塞和高吞吐量。
在轮询阶段，Node.js 如何决定何时“等待”或“继续”？
这个决策过程是轮询阶段最有趣、也最复杂的部分之一，因为它直接影响到应用的响应性。我个人觉得，这有点像一个经验丰富的调度员在指挥交通。
当事件循环进入轮询阶段，它首先会检查poll队列里是否有已经准备好的I/O回调。如果有，它会毫不犹豫地执行它们，直到队列清空。这就像交通顺畅时，车辆（回调）一辆接一辆地通过。
但如果poll队列空了，调度员就会开始思考：我应该继续等待新的I/O事件，还是有更紧急的任务需要处理？
-
检查setImmediate： 它会立即查看setImmediate队列。如果这个队列不为空，这意味着有任务被明确地安排在当前I/O周期结束后执行。Node.js会立即“决定”不等待I/O，而是直接跳到check阶段去执行setImmediate的回调。这就像调度员发现有救护车（setImmediate）要通过，立刻放行，不再等待普通车辆。
-
检查timers： 如果setImmediate队列也空了，Node.js会检查timers队列中是否有即将到期的定时器。如果存在，它会计算出离现在最近的那个定时器还有多久到期。然后，它会在poll阶段“等待”最多这个时间长度。这意味着它会在这里阻塞，但不会无限期阻塞，而是会等到有新的I/O事件到来，或者等到最近的定时器到期，然后它就会跳回timers阶段去处理定时器。这就像调度员知道下一班列车（定时器）还有多久到站，他会合理安排等待时间。
-
完全阻塞： 如果poll队列空了，setImmediate队列也空了，并且timers队列里也没有即将到期的定时器（或者根本没有定时器），那么Node.js就会在这里进入一个“完全阻塞”的状态。它会一直等待，直到有新的I/O事件发生（比如一个网络连接进来，或者一个文件读取完成）。这是事件循环真正“休息”的时候，它将CPU资源释放给操作系统，直到被唤醒。
这个决策逻辑确保了Node.js在没有任务时能高效地休眠，而在有任务时能迅速响应，从而实现其非阻塞的特性。
开发者如何优化或利用轮询阶段的行为？
理解轮询阶段的工作方式，对于我们开发者来说，简直就是一把利器，能帮助我们写出更健壮、更高效的代码，甚至在某些情况下，能帮你排查那些“为什么我的setTimeout(fn, 0)比setImmediate慢？”这类看似玄学的问题。
首先，最直观的，就是避免在事件循环中执行长时间的同步操作。这包括在poll阶段的回调函数里，如果你写了一个计算量巨大的同步循环，或者同步地读取了一个超大文件，那么整个事件循环都会被阻塞。这意味着，即使有新的网络请求进来，或者其他I/O操作完成了，它们的回调也无法被执行，因为轮询阶段被你的同步代码卡住了。解决办法通常是使用异步API，或者将重计算任务放到工作线程（worker_threads）中去执行，让主线程保持轻盈。
其次，巧妙利用setImmediate和setTimeout(fn, 0)的区别。我们知道，setImmediate会在当前poll阶段结束后，在check阶段立即执行。而setTimeout(fn, 0)则会在下一个timers阶段尝试执行，但它受系统调度和当前事件循环状态的影响，不保证零毫秒后立即执行。如果你想在处理完当前批次的I/O事件后，立即执行某个任务，并且不希望它被未来的I/O事件插队，那么setImmediate往往是比setTimeout(fn, 0)更好的选择。这对于一些需要“在当前周期内，但稍微延后”执行的任务非常有用。
再者，理解Promise和async/await的执行时机。Promise的回调（.then(), .catch(), .finally()）和async/await中的await之后的代码，都会被放入微任务队列。这个队列的优先级极高，它会在当前宏任务（比如一个poll阶段的回调）执行完毕后，立即清空。这意味着，如果你在一个poll阶段的回调中触发了一个Promise，它的.then()回调会在当前轮询阶段的回调完全执行完毕后，但在事件循环进入下一个阶段之前，就被执行。这种机制使得异步代码的执行顺序更加可控，也更符合直觉。
最后，如果你在做一些高性能的网络服务，深入理解轮询阶段如何处理I/O事件，可以帮助你优化I/O批处理。例如，如果你需要向数据库写入大量数据，批量插入通常比单条插入更高效，因为它减少了I/O操作的次数，也减少了事件循环在不同阶段之间切换的开销。当然，这更多是数据库层面的优化，但其背后是对事件循环I/O处理模式的理解。
总的来说，轮询阶段是Node.js事件循环的“大脑”，理解它的运作方式，能让我们写出更符合Node.js设计哲学的代码，避免常见的性能陷阱，并能更精准地控制异步任务的执行时机。
