Node.js事件循环共六个阶段：timers、pending callbacks、idle/prepare、poll、check、close callbacks；其中poll阶段负责执行I/O回调并轮询新I/O事件，若队列为空且无到期定时器则底层libuv阻塞等待，而非JS线程阻塞。
JavaScript 的事件循环本身不直接处理 I/O 轮询阶段的阻塞，因为 I/O 轮询（如网络请求、文件读写）发生在 Node.js 的底层 C++ 运行时（libuv），而非 JavaScript 主线程。事件循环只是协调和调度——它把完成的 I/O 任务结果从 libuv 的轮询队列“取出来”，推入 JavaScript 的回调队列（如 poll 阶段触发的 setTimeout、setImmediate 或 I/O 回调）。
I/O 轮询阶段本身不会阻塞事件循环，但可能“延长”该阶段
在 Node.js 的事件循环中，poll 阶段主要做两件事：执行 I/O 回调（如 fs.readFile 的回调）、以及等待新 I/O 事件就绪（即轮询）。当 poll 队列为空且没有待处理的定时器时，事件循环会进入“等待状态”——此时 libuv 确实会阻塞在系统调用（如 epoll_wait 或 kqueue）上，但这属于底层高效休眠，并非 JS 层面的阻塞。一旦有 I/O 完成，内核唤醒 libuv，事件循环立刻继续。
- 如果 poll 队列不为空，事件循环会同步执行所有就绪的 I/O 回调，直到队列清空或达到系统限制（避免饿死其他阶段）
- 如果 poll 队列为空，但存在已到期的定时器（
setTimeout/setInterval），事件循环会退出 poll 阶段，进入timer阶段 - 如果 poll 队列为空且无到期定时器，事件循环才会阻塞等待 I/O —— 这是设计行为，不是缺陷
真正造成“阻塞感”的通常是 CPU 密集型操作，而非 I/O 轮询
很多人误以为 I/O 轮询卡住了事件循环，实际更常见的是：在 I/O 回调里执行了同步耗时操作（如大数组排序、正则回溯、JSON 解析超大字符串），导致后续阶段（包括下一轮 poll）无法及时执行。I/O 本身由操作系统异步完成，JS 只负责处理结果。
- 避免在回调中做 heavy sync work；可拆分为微任务分片（
queueMicrotask）或使用worker_threads - 对大文件读取，优先用流式处理（
fs.createReadStream）而非fs.readFile一次性加载 - 网络请求中解析响应体前，先检查
content-length或流式解析，防止 OOM 或长阻塞
可通过调试手段确认是否真被 I/O 轮询拖慢
单纯看代码很难判断，需结合运行时指标：
立即学习“Java免费学习笔记（深入）”；
- 使用
process.monitorEventLoopDelay()（Node.js 19.6+）监测事件循环延迟，若延迟突增但 I/O 活跃度低，说明是 JS 执行过久，而非 poll 阻塞 - 用
node --trace-events-enabled --trace-event-categories node,node.async_hooks生成 trace 文件，在 Chrome DevTools 中查看各阶段耗时分布 - 检查
libuv层是否真在等待：通过strace -e epoll_wait,node（Linux）观察系统调用阻塞时间
主动控制 poll 行为的实用方式
Node.js 提供了有限但有效的干预手段：
-
setImmediate()明确将回调推迟到 poll 阶段之后（check 阶段），适合拆分长任务 -
process.nextTick()在当前操作结束后、进入下一事件循环阶段前执行，优先级高于 microtask，慎用以防饥饿 -
timers.setImmediate()和timers.setTimeout(fn, 0)的行为差异会影响 poll 阶段是否被跳过——合理利用可优化调度顺序 - 启用
--max-http-header-size或--max-old-space-size等参数，避免因内存/解析限制间接拉长 I/O 处理链
事件循环与 I/O 轮询的关系是协作而非包含：JS 不阻塞 I/O，I/O 也不阻塞 JS 主线程——关键在于别让 JS 回调自己变成瓶颈。理解这个分工，才能准确诊断和优化真实场景中的延迟问题。
