简介

Node.js 作为 JavaScript 后端运行环境，其核心优势在于高并发处理能力和非阻塞 I/O 模型。

特点：

• 高并发处理：单线程事件循环高效处理大量并发连接
• I/O 密集型任务：非阻塞 I/O 模型避免线程切换开销，不适合 CPU 密集型任务（如视频编码）
• 前后端技术统一：JavaScript 全栈开发

注意：
Node.js 不是多线程的，主线程是单线程，但通过线程池处理部分操作

使用场景

• Web 服务器（如 REST API）
• 实时应用（如聊天、协作工具）
• 微服务架构中的网关 / 代理服务
• 数据管道和流处理

分层架构

1. 底层系统
   • 操作系统：Linux、Windows、macOS 等
   • 系统调用：文件操作、网络通信等底层 API
2. C/C++ 核心库
   • V8 引擎：Google 开发的 JavaScript 执行引擎，负责编译和执行 JS 代码
   • libuv：Node.js 自主开发的跨平台异步 I/O 库，封装操作系统底层 API
   • OpenSSL：提供加密和安全通信功能
   • zlib：压缩 / 解压缩数据
3. JavaScript 核心模块
   • 如 fs（文件系统）、net（网络）、http（HTTP 服务器）等，通过 Node.js 绑定层调用底层 C/C++ 库
4. 用户应用层
   开发者编写的 Node.js 应用代码

事件循环

Node.js 的事件循环（Event Loop）是其异步 I/O 的核心机制，由 Libuv 库实现。它将事件循环分为 7 个主要阶段，每个阶段按特定顺序执行不同类型的回调任务。以下是各阶段的详细说明：

1. timers 阶段（定时器阶段）
2. pending callbacks 阶段（待定回调阶段）
3. idle, prepare 阶段（内部准备阶段）
4. poll 阶段（轮询阶段）
5. check 阶段（检查阶段）
6. close callbacks 阶段（关闭回调阶段）
7. nextTick 与 microtasks（穿插执行，不属于主阶段）

setTimeout 与 setImmediate 的执行顺序

在 Node.js 中，setTimeout 和 setImmediate 的执行顺序取决于它们的调用位置和事件循环的状态。这是一个常见的面试考点，也是理解 Node.js 异步机制的关键。

核心区别

1. setTimeout(callback, 0)

• 理论上立即执行回调，但实际延迟 ≥ 1ms（受系统调度影响）。
• 回调在事件循环的 Timer 阶段执行。

2. setImmediate()

• 设计用于在当前轮询阶段结束后立即执行回调。
• 回调在事件循环的 Check 阶段执行。

执行顺序

1. 在主模块中调用的时候
   当两者在主模块中调用的时候，执行顺序不固定，取决于 JavaScript 引擎的初始化速度和系统负载。

// 示例1：主模块中直接调用
setTimeout(() => {console.log('定时器回调');
}, 0);setImmediate(() => {console.log('setImmediate 回调');
});// 可能的输出：
// 1. 定时器回调 → setImmediate 回调（常见情况）
// 2. setImmediate 回调 → 定时器回调（极少情况，系统负载高时可能发生）

原因

• setTimeout(…, 0) 实际延迟 ≥ 1ms，如果系统繁忙，可能超过 1ms。
• 如果延迟超过 1ms，事件循环进入 Check 阶段时，定时器尚未触发，导致 setImmediate 先执行。

2. 在异步 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 的回调。