简介
Node.js 作为 JavaScript 后端运行环境，其核心优势在于高并发处理能力和非阻塞 I/O 模型。
特点：
- 高并发处理：单线程事件循环高效处理大量并发连接
- I/O 密集型任务：非阻塞 I/O 模型避免线程切换开销，不适合 CPU 密集型任务（如视频编码）
- 前后端技术统一：JavaScript 全栈开发
注意：
Node.js 不是多线程的，主线程是单线程，但通过线程池处理部分操作
使用场景
- Web 服务器（如 REST API）
- 实时应用（如聊天、协作工具）
- 微服务架构中的网关 / 代理服务
- 数据管道和流处理
分层架构
- 底层系统
- 操作系统：Linux、Windows、macOS 等
- 系统调用：文件操作、网络通信等底层 API
- C/C++ 核心库
- V8 引擎：Google 开发的 JavaScript 执行引擎，负责编译和执行 JS 代码
- libuv：Node.js 自主开发的跨平台异步 I/O 库，封装操作系统底层 API
- OpenSSL：提供加密和安全通信功能
- zlib：压缩 / 解压缩数据
- JavaScript 核心模块
- 如 fs（文件系统）、net（网络）、http（HTTP 服务器）等，通过 Node.js 绑定层调用底层 C/C++ 库
- 用户应用层
开发者编写的 Node.js 应用代码
事件循环
Node.js 的事件循环（Event Loop）是其异步 I/O 的核心机制，由 Libuv 库实现。它将事件循环分为 7 个主要阶段，每个阶段按特定顺序执行不同类型的回调任务。以下是各阶段的详细说明：
- timers 阶段（定时器阶段）
- pending callbacks 阶段（待定回调阶段）
- idle, prepare 阶段（内部准备阶段）
- poll 阶段（轮询阶段）
- check 阶段（检查阶段）
- close callbacks 阶段（关闭回调阶段）
- nextTick 与 microtasks（穿插执行，不属于主阶段）
setTimeout 与 setImmediate 的执行顺序
在 Node.js 中，setTimeout 和 setImmediate 的执行顺序取决于它们的调用位置和事件循环的状态。这是一个常见的面试考点，也是理解 Node.js 异步机制的关键。
核心区别
- setTimeout(callback, 0)
- 理论上立即执行回调，但实际延迟 ≥ 1ms（受系统调度影响）。
- 回调在事件循环的 Timer 阶段执行。
- setImmediate()
- 设计用于在当前轮询阶段结束后立即执行回调。
- 回调在事件循环的 Check 阶段执行。
执行顺序
-
在主模块中调用的时候
当两者在主模块中调用的时候，执行顺序不固定，取决于 JavaScript 引擎的初始化速度和系统负载。// 示例1：主模块中直接调用
setTimeout(() => {
console.log('定时器回调');
}, 0);setImmediate(() => {
console.log('setImmediate 回调');
});// 可能的输出：
// 1. 定时器回调 → setImmediate 回调（常见情况）
// 2. setImmediate 回调 → 定时器回调（极少情况，系统负载高时可能发生）
原因
- setTimeout(..., 0) 实际延迟 ≥ 1ms，如果系统繁忙，可能超过 1ms。
- 如果延迟超过 1ms，事件循环进入 Check 阶段时，定时器尚未触发，导致 setImmediate 先执行。
-
在异步 I/O 回调中调用
当两者在异步 I/O 回调（如 fs.readFile）中调用时，setImmediate 总是先于 setTimeout 执行。// 示例2：在I/O回调中调用
const fs = require('fs');fs.readFile(__filename, () => {
setTimeout(() => {
console.log('定时器回调');
}, 0);setImmediate(() => {
console.log('setImmediate 回调');
});
});// 输出顺序固定为：
// setImmediate 回调 → 定时器回调
原因
- 异步 I/O 回调在Poll 阶段执行。
- 执行完毕后，事件循环进入Check 阶段，执行 setImmediate 的回调。
- 下一轮循环的 Timer 阶段才会执行 setTimeout 的回调。