Node.js 提供了两种原生的并行方案：cluster 创建多进程，worker_threads 创建多线程。它们的底层机制、资源开销、通信方式和适用场景都有显著差异。理解这些差异，是合理选择并行策略的前提。
多进程与多线程的本质差异
| 维度 | cluster（多进程） | worker_threads（多线程） |
|------|------------------|-------------------------|
| 并行单位 | 独立的 Node.js 进程，每个进程拥有独立的 V8 实例、独立的内存空间和独立的事件循环 | 同一个进程内的多个线程，共享进程的内存空间，但有独立的 V8 隔离（每个线程有自己的事件循环） |
| 内存开销 | 每个进程占用约 30-50 MB 内存，CPU 核心数较多时总内存消耗成倍增长 | 每个线程额外开销约 2-5 MB，远低于进程 |
| 通信方式 | 进程间通信（IPC），通过 process.send() 传递序列化消息，支持句柄传递（如套接字） | postMessage 传递结构化数据（利用结构化克隆算法或转移所有权）、SharedArrayBuffer 共享内存 |
| 启动速度 | 较慢，需要启动新的 V8 实例和初始化环境 | 较快，复用现有进程的资源 |
| 崩溃隔离 | 一个进程崩溃不会影响其他进程，天然隔离 | 线程崩溃可能导致整个进程退出（需自行捕获错误） |
| 安全隔离 | 高，不同进程的内存空间完全独立 | 低，共享内存可能引入竞态条件，需开发者保证线程安全 |
| 适用场景 | 多核 CPU 利用、服务可用性保障、无状态 Web 服务的水平扩展 | CPU 密集型计算任务的分解、共享内存的高性能计算 |
cluster 的优势场景
cluster 的核心价值在于利用多核 CPU 提升服务吞吐量，同时提供进程级容错。它通过主进程（master）派生多个工作进程（worker），工作进程监听同一个端口（由操作系统负载均衡或主进程轮询分发），实现简单的水平扩展。
适合 cluster 的典型场景：
- 高并发 Web 服务：比如 Express、Koa 应用。通过 fork 多个工作进程，充分利用服务器的所有 CPU 核心，使得总吞吐量接近单进程的 N 倍。通常使用 PM2 的 cluster 模式或原生
cluster模块实现，一行配置即可提升服务能力。
- 进程守护与零停机重启：
cluster使得主进程可以监控工作进程的健康状态。当某个工作进程意外退出时，主进程可以立即新 fork 一个补充，保证服务的高可用性。在版本更新时，也可以逐个重启工作进程，实现零停机部署。
- 无状态的水平扩展：因为每个进程都独立，天然无共享状态，只需配合外部存储（Redis、数据库）保存会话或缓存，就能轻松扩展。不需要考虑线程间的数据竞争，代码编写更安全。
cluster 的局限：
- 内存消耗大，如果服务器核心数很多（如 64 核），fork 64 个进程可能会消耗数 GB 内存。
- 无法高效地处理单任务内的 CPU 密集计算——一个大计算任务依然会阻塞整个工作进程，其他请求只能等待下一个空闲进程。
worker_threads 的优势场景
worker_threads 的设计初衷是把 CPU 密集任务从主线程中剥离，保持主线程的响应性，同时也适用于需要共享内存的并行计算。线程之间的通信延迟更低，内存占用更少。
适合 worker_threads 的典型场景：
- CPU 密集型计算：如数据加密/解密、图像处理、大规模 JSON 解析、复杂数学运算等。主线程将计算任务丢给 Worker 线程，自己继续处理其他请求。计算完成后通过
postMessage取回结果。一个典型的用法是使用线程池（例如piscina库）来约束并发线程数并复用线程实例。
- 共享内存的高性能计算：通过
SharedArrayBuffer和Atomics实现线程间的细粒度同步，适合实时数据分析、科学计算等需要高频共享状态的场景。
- 嵌入式或受限环境：如 Electron 应用，希望在渲染进程之外执行耗时的 Node.js 代码，避免阻塞 UI。线程比 fork 进程更轻量，启动更快。
- 并行 I/O 但需要合并结果：虽然 I/O 密集型操作本不需要多线程，但某些情况下需要同时读取多个大文件并合并处理，Worker 线程可以并行读取并处理，利用多核加速 I/O 处理后的计算部分。
worker_threads 的局限：
- 线程间共享内存容易引入竞争和死锁，需要开发者慎重使用
Atomics或设计无共享的独立计算单元。 - 单个 Worker 线程的崩溃可能杀死整个进程，需要做好错误隔离。
- 与
cluster不同，worker_threads本身不解决多核利用问题，如果一台机器有多个核心，仍需要结合cluster或启动多个实例来完全利用所有 CPU。
真实场景中的混合使用
现实中，两种方案并不互斥。许多高性能 Node.js 应用会同时使用 cluster 和 worker_threads：
- 使用
cluster或 PM2 的 cluster 模式启动等于 CPU 核心数的进程，然后在每个工作进程内部，将 CPU 密集任务（如报表生成）交给worker_threads线程池处理，保证主线程始终能快速响应新请求。 - 对于已经容器化的微服务，通常每个容器只分配 1-2 个 vCPU，此时在容器内使用
cluster反而可能增加不必要的内存开销，直接在单进程中使用worker_threads可能是更合理的选择。
选型决策清单
在实际选型时，可以通过以下问题辅助判断：
- 任务是 CPU 密集还是 I/O 密集？
- 如果主要瓶颈是 I/O（网络、数据库、文件），
cluster多进程足以提升吞吐量。 - 如果单个请求包含大量计算（如密码学、图像滤镜），应该使用
worker_threads避免阻塞主线程。
- 是否需要进程级容错？
- 如果需要高可用且无法接受进程崩溃影响整体服务，
cluster的进程隔离更可靠。
- 内存资源是否紧张？
- 在内存受限的容器或 Serverless 环境中，多线程方式更节省内存。
- 是否需要共享内存？
- 需要频繁零拷贝地共享大量数据时，
worker_threads+SharedArrayBuffer是唯一选择。
总结而言，cluster 解决的是服务的水平扩展和可用性问题，而 worker_threads 解决的是单任务的计算密集瓶颈问题。理解它们的定位差异，可以让架构设计更加清晰合理。