Node.js 是一个开源的、跨平台的 JavaScript 运行时环境。
所谓运行时runtime，是指程序声明周期中从开始执行到完成退出的阶段，除了运行时，还时有提及的编译阶段是 compile time，链接阶段是 link time，在前面的阶段预先做了通常在后面才方便做的事叫 ahead of time
Node.js 是一个异步事件驱动运行时 (asynchronous event-driven JavaScript runtime) 与
面试补充（2026-07-22）
本节为后续补充，用于资深软件工程师基础面试复习；上文保留原始笔记。
V8、Node.js bindings、libuv 与操作系统
可以把一次 Node.js I/O 调用理解为多层协作：
- V8 解析、编译和执行 JavaScript，管理 JavaScript 堆与垃圾回收。
- Node.js C/C++ bindings 把 JavaScript API 连接到操作系统能力、内置库和 libuv。
- libuv 提供事件循环、跨平台异步抽象和线程池等能力。
- 操作系统 提供网络、文件、进程、计时器等底层机制。网络 I/O 常利用 epoll、kqueue、IOCP 等系统能力；并非每个异步操作都占用一个 libuv 工作线程。
因此，“Node.js 异步是因为有一个线程池包办所有 I/O”不准确。文件系统、部分 DNS、压缩和部分加密任务会使用 libuv 线程池；网络 socket 通常由操作系统的事件通知机制驱动。
“Node.js 是单线程”的准确边界
通常所说的单线程，是指一个 Node.js isolate 中的 JavaScript 回调在同一时刻由一个主线程执行。这带来两个结果：
- 普通业务代码不必像共享内存多线程那样为每次对象访问加锁。
- 一个长时间占用 CPU 的 JavaScript 回调会阻塞同一事件循环上的所有连接。
但 Node.js 进程内部还可能有 V8 辅助线程、libuv 线程池和 Worker Threads，操作系统也在并发处理 I/O。多进程部署时，每个进程有独立的 V8 堆和事件循环。面试回答应区分“JavaScript 执行模型”和“整个运行时只有一个线程”。
事件循环、nextTick 与微任务
libuv 事件循环包含 timers、pending callbacks、poll、check、close callbacks 等阶段。面试中更值得掌握的是稳定关系：
- 当前 JavaScript 调用栈必须先清空，其他回调才有机会执行。
- Promise reaction 和
queueMicrotask()属于微任务，会在进入下一个事件循环阶段前被清空。 process.nextTick()是 Node.js 的特殊队列，优先于常规微任务处理；递归安排它可能让事件循环和 I/O 长时间得不到机会。setImmediate()的回调进入 check 阶段；timer 在达到阈值后才有资格执行，不是精确实时调度。- 在顶层代码里比较
setTimeout(fn, 0)和setImmediate(fn)的先后不可靠；在特定 I/O 回调中通常更容易观察到setImmediate()先进入 check 阶段。
不同 Node.js/libuv 版本曾调整 timer 的阶段行为，运行环境和周围 I/O 也会影响输出。资深回答应解释为什么顺序成立、哪些关系稳定，并能用最小实验确认目标版本，而不是背一串脱离上下文的日志。
I/O 密集和 CPU 密集任务
异步 I/O 提高的是等待期间的并发利用率，不会让 CPU 计算自动变快。选择方案前先给任务分类：
- 数据库、网络和磁盘等待为主：用异步 API、连接池、超时、背压和并发上限。
- JSON 大对象解析、图像处理、路径规划或压缩计算为主：测量 CPU 与事件循环延迟，必要时拆分、使用 Worker Threads、独立服务或原生实现。
- 大量细碎任务：即使单次很快，也可能因队列无界和对象分配造成延迟与 GC 压力。
不要用“接口平均响应很快”替代诊断。至少同时观察延迟分位数、吞吐量、事件循环延迟、CPU、内存、GC、下游耗时和队列长度。
Worker、子进程与多进程
| 机制 | 适合场景 | 主要代价与边界 |
|---|---|---|
| Worker Threads | 同一应用内的 CPU 密集 JavaScript，可传输对象或使用共享内存 | 仍在同一进程，需设计任务池、取消、崩溃处理和数据传输 |
| Child Process | 调用外部程序、隔离不可信或易崩溃任务、使用不同运行时 | IPC 和启动成本更高，但地址空间和故障隔离更清晰 |
| 多 Node.js 进程 | 利用多核承载独立请求或消费者 | 会话、定时任务和连接状态不能默认只存在一份 |
| Cluster | 多进程共享监听端口的 Node.js 内置方案 | 需要理解调度和进程生命周期，生产中也可由容器或进程管理器承担 |
不要为了“多核”把每个请求临时创建为一个 Worker。生产服务通常使用有上限的池，并定义排队长度、超时、取消和过载策略。机器人或工业控制命令还要考虑顺序和状态，不能为了并行吞吐破坏设备级串行约束。
Buffer、堆外内存与内存诊断
Buffer 表示字节数据，常用于网络、文件和二进制协议。其底层内存不一定全部计入 V8 的 heapUsed，因此只看 JavaScript 堆可能漏掉问题。
排查进程内存增长时至少区分：
heapUsed持续增长：检查被集合、闭包、缓存、监听器或定时器长期引用的对象。external/arrayBuffers增长：检查 Buffer、TypedArray、原生模块和二进制数据生命周期。- RSS 增长但堆稳定：还可能来自原生分配、线程栈、内存碎片和运行时保留。
- GC 频繁且延迟升高：可能是分配速率过高，不一定是对象永远无法回收。
正确流程是先用指标确认趋势和关联请求，再通过 heap snapshot、allocation profile、CPU profile、诊断报告或受控压测定位引用链。不要一看到内存高就手动调用 GC 或直接增大堆上限。
错误边界、超时和取消
Promise rejection 应在能够决定恢复策略的边界被 await、返回或捕获。EventEmitter 的 'error' 事件若无人监听可能终止进程；流和回调 API 也有各自的错误通道。混用这些模型时要明确错误如何汇总。
下面的超时只限制单次网关请求：
1 | async function loadDeviceState(deviceId: string): Promise<unknown> { |
必须区分三个概念：
- 超时限制愿意等待多久，但不一定撤销已经到达设备的命令。
- 取消尝试终止本地或下游工作，需要调用链真正传播
AbortSignal才有效。 - 重试再次发起操作，只能在失败分类、次数、退避和幂等语义明确时使用。
读取状态通常容易做幂等重试；机械臂移动、PLC 写入或扣款等命令可能已经部分执行，盲目重试会产生第二次动作。需要命令 ID、状态查询、去重或业务补偿，而不是一个通用重试装饰器。
未捕获异常和未处理 rejection 表明应用越过了预期错误边界。不要依赖某个 Node.js 版本的默认行为继续提供服务；通常应记录足够上下文，触发受控停机并由外部管理器重启。uncaughtException 是最后的清理边界，不是恢复到健康状态的证据。
优雅停机、幂等与可观测性
收到 SIGTERM 等停止信号后，一个服务通常按以下顺序收敛：
- 标记 readiness 为不可接流量，并停止接受新任务。
- 为在途请求和任务设置总截止时间，允许完成、主动取消或记录未完成状态。
- 停止消息消费者，关闭设备连接、数据库连接池和其他资源。
- 尽力刷新关键日志、审计记录和指标，但不能无限等待。
- 正常完成时退出 0；无法安全收敛或发生致命错误时退出非 0，由外部管理器决定重启。
“关闭 HTTP server”只是不再接受新连接，不能自动处理所有 WebSocket、队列消费者和后台定时器。服务必须维护资源所有权，并让关闭流程可重复调用、具有截止时间且可测试。
日志需要关联请求、设备、命令和任务。可使用 AsyncLocalStorage 传播 correlation ID，但仍要控制敏感字段和日志量。指标至少覆盖请求量、错误率、延迟分位数、事件循环延迟、内存、队列深度和下游依赖；trace 用于解释一次请求跨服务的耗时路径。
工业遥测网关的诊断场景
假设 Node.js 网关接收机器人和 PLC 遥测，运行数小时后延迟上升。应先区分：
- 事件循环延迟升高且 CPU 高：查找同步解析、大循环、频繁序列化、日志格式化和热点函数。
- 事件循环延迟正常但下游耗时高：检查数据库、消息代理、设备连接和网络，并设置超时与隔离。
- 堆持续增长：检查按设备保存但无淘汰的 Map、监听器、未完成 Promise 和缓存。
- external/RSS 增长：检查 Buffer、图像帧、二进制协议和原生模块。
- 队列持续增长：生产速度超过消费速度，应有背压、合并、丢弃策略或有界队列，不能只扩容内存。
测量后再选择 Worker、Stream、批处理、限流、过载丢弃或多进程。对于安全相关设备状态，还要区分哪些消息允许采样或覆盖旧值，哪些报警与命令必须可靠保留。
常见追问与回答边界
Node.js 适合高并发，是否意味着适合所有高负载任务？
不意味着。它擅长大量 I/O 等待并发；CPU 密集回调会阻塞事件循环，需要隔离计算或选择更合适的执行方式。
增加 libuv 线程池大小能否解决所有性能问题？
不能。它只影响使用该线程池的部分 API，还可能增加资源竞争；网络 I/O、JavaScript CPU 热点和无界队列不会因此自动消失。
为什么平均延迟正常，用户仍感觉偶尔卡死？
平均值会掩盖尾延迟。应看 p95/p99、事件循环延迟、GC pause、慢依赖和队列等待，并关联具体请求 trace。
捕获 uncaughtException 后为什么不建议继续运行？
异常可能发生在修改一半的状态或资源操作中，进程是否仍满足不变量无法确认。处理器适合记录和受控退出，不适合作为长期恢复机制。
