Node.js高效性源于事件循环与异步I/O。事件循环由libuv实现，分阶段执行回调：Timers→Pending→Poll→Check→Close，每轮循环处理宏任务（如setTimeout、I/O）并在阶段间优先执行微任务（Promise.then、process.nextTick）。异步I/O将文件或网络请求交由系统或线程池处理，完成时在Poll阶段触发回调，避免阻塞主线程。微任务中process.nextTick优先级最高，其次为Promise.then，应在阶段结束后立即执行。需注意：网络I/O通常不使用线程池，而文件操作、DNS等才使用，默认线程池大小为4。避免长时间同步操作阻塞事件循环，合理使用setImmediate或nextTick控制执行顺序，防止饥饿问题。掌握这些机制可提升应用性能与可靠性。
Node.js 的高效性主要来源于其非阻塞 I/O 和事件驱动架构，而核心机制就是 事件循环（Event Loop） 与 异步 I/O。理解这两者的工作原理，有助于写出更高效、更可靠的 Node.js 应用。
事件循环的基本结构
Node.js 基于 V8 引擎运行 JavaScript，而 JavaScript 是单线程的。为了处理并发操作，Node.js 使用了事件循环来协调任务执行顺序。
事件循环不是在 JavaScript 层实现的，而是由底层库 libuv 提供支持。它不断检查各种任务队列，并按阶段依次执行回调函数。
事件循环的每个“tick”会经历以下几个阶段：
- Timers 阶段：执行 setTimeout 和 setInterval 回调。
- Pending callbacks：执行某些系统操作（如 TCP 错误）的回调。
- Idle, prepare：内部使用，可忽略。
- Poll 阶段：收集新 I/O 事件，执行 I/O 回调（最重要阶段之一）。
- Check 阶段：执行 setImmediate 的回调。
- Close callbacks：执行 close 事件的回调，比如 socket.close()。
每次循环都会按顺序走完这些阶段，然后回到开头继续下一轮。
异步 I/O 的工作流程
当发起一个文件读取或网络请求时，Node.js 不会等待操作完成，而是把任务交给底层系统处理。
以 fs.readFile 为例：
- 调用 fs.readFile 时，Node.js 将请求传递给线程池（由 libuv 管理）或操作系统（如果支持异步系统调用，如 Linux 的 epoll）。
- 主线程立即返回，继续执行后续代码，不会被阻塞。
- 当 I/O 操作完成，结果会被放入事件队列。
- 在下一次事件循环的 Poll 阶段，系统检测到完成的 I/O 事件，触发对应的回调函数。
这种设计让 Node.js 能以少量线程支持大量并发连接，特别适合 I/O 密集型应用。
微任务与宏任务的执行顺序
除了事件循环的阶段，还需要理解任务的分类：
- 宏任务（Macrotask）：包括 setTimeout、setInterval、I/O、setImmediate、close 事件等，每个阶段处理一个宏任务队列。
- 微任务（Microtask）：包括 Promise.then、process.nextTick。它们在每个阶段结束后立即执行，且优先级高于下一个宏任务。
特别注意：process.nextTick 虽然属于微任务，但它实际上在每个阶段之间都会被清空，优先级甚至高于普通微任务。
举例来说：
Promise.resolve().then(() => console.log('promise'));process.nextTick(() => console.log('nextTick'));
console.log('sync');
输出顺序是：sync → nextTick → promise，因为 nextTick 优先级最高。
常见误区与优化建议
很多人误以为所有异步操作都走线程池，其实并非如此：
- 网络 I/O 在大多数平台上由事件驱动（如 epoll/kqueue），不占用线程池。
- 文件 I/O、DNS lookup、加密操作等才真正使用 libuv 的线程池，默认大小为 4，可通过 UV_THREADPOOL_SIZE 调整。
避免在事件循环中执行长时间同步操作（如大数组排序、JSON 解析过大），否则会阻塞整个主线程，影响响应速度。
合理使用 setImmediate 或 process.nextTick 可以控制回调执行时机，但不要滥用，尤其是 nextTick，过度使用会导致饥饿问题。
基本上就这些。掌握事件循环和异步 I/O 的协作方式，能帮助你更好理解 Node.js 的行为，写出更符合预期的异步代码。
