什么时候该用 Node.js？（适用与不适用的场景）
Node.js 适合实时应用、高并发 API、微服务、SPA 后端、流处理；不适合 CPU 密集计算、重型科学计算。本文给出判断框架：看 I/O 模型、团队技能与生态匹配度。
**判断核心：Node.js 的主场是"I/O 密集 + 高并发 + 实时性"，短板是"CPU 密集计算"。**对号入座即可。
适合的场景
实时 Web 应用：聊天、在线游戏、协同编辑、行情推送——事件驱动模型 + WebSocket 是绝配，连接容量取决于应用负载、内存、网络和配置，需实测。
高并发 API 与微服务：请求的大部分时间在等数据库/下游接口（I/O），Node 的非阻塞模型可以让多个请求交错等待，但实际并发容量需测量。
SPA 和动态网站后端：前后端同语言（JavaScript/TypeScript），一套类型定义、一套校验逻辑两头复用，全栈效率极高。
流处理与代理层：调用外部转码器的流式管道、文件上传中转（CPU 密集转码本身不应放在主事件循环）、API 网关——Node 的 Stream 抽象处理这类场景很顺手。
Serverless 函数：冷启动与内存开销取决于依赖、初始化工作和平台，是 FaaS 的热门运行时。
不适合的场景
- CPU 密集计算：主线程上的同步图像处理、复杂加密和数学计算会阻塞事件循环；部分异步原生 API 使用 libuv 线程池，不应一概而论（可用 worker_threads 或独立服务缓解，但已不是 Node 的主场）；
- 重型科学计算/机器学习训练：Python 生态更合适；
- 强类型大型企业系统的保守选型：Java/Go 的静态类型和线程模型在超大型团队治理下仍有优势（TypeScript 能缓解很多）。
决策清单
问自己三个问题：
- 请求的瓶颈是 I/O（数据库、网络、文件）还是 CPU？→ I/O 选 Node 合适；
- 团队主力语言是什么？→ 前端团队扩展全栈，Node 学习成本最低；
- 需要的库生态成熟吗？→ npm 是全球最大包仓库，基本不缺轮子。
初选后，用代表性请求测量事件循环延迟、CPU 使用和响应时间，区分计算阻塞与等待下游，验证是否需要拆分计算任务。
常见问题（FAQ）
Q：Node.js 单线程怎么做多核利用？
用 cluster 模块开多进程，或容器化跑多个实例由负载均衡分发。worker_threads 在 Node 18 之前已提供，可用于 CPU 任务；它不等同于 libuv 原生线程池，需要自行或通过库管理任务池。
Q：Node 和 Go 怎么选？
高并发 I/O、迭代需求与前端团队经验可作为选择 Node 的依据；Go 的部署方式与生态也可纳入比较，吞吐和内存需用同等负载实测，不能仅凭语言保证。
Q：现在 Bun/Deno 出来了，Node 还值得学吗？
值得。Node 生态与生产实践积累最深，Bun/Deno 的 API 大量兼容 Node，学会 Node 等于一通百通。
