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