“Node.js 不行了”?性能争议中的误解与选择真相

网上最近热传的一篇文章《我们向 Go、Rust 和 Node 投入了一百万并发用户进行压测》掀起了一波"Node.js 过时论"。

文章作者模拟了一场千万级别的请求压测,结论是:Node.js 表现最差,Rust 和 Go 远胜一筹。

但你仔细读下去就会发现,这种测试不是 Node 不行,而是测试设计本身存在偏差。这正是许多"Node.js 批评"中的盲点所在。


一、测试结果:Node.js 被"吊打"的背后

这篇文章中,作者搭建了一个包含 PostgreSQL、Redis、外部 API 的接口 /order,然后对 Go、Rust、Node 三种实现进行并发压力测试。

测试结果显示:在百万并发下,Node.js 请求掉线率极高,内存和响应时间都远逊于 Rust 与 Go。

听起来似乎很合理 ------ 单线程的 Node 确实处理不了高 CPU 压力。可真正的问题在于:Node.js 的测试代码写得并不合理,甚至可以说是反面教材。


具体问题如下:

  • 每次请求都重新 new 一个 HTTP 客户端,而不是像 Go 一样用全局共享连接池。
  • Redis 调用出现错误时没有显式处理,导致整个请求链断裂。
  • axios 请求没有设置超时,默认会无限挂起,极易放大负载问题。

这些设计缺陷让 Node.js 的性能大打折扣,但这并不能代表它在现实工程中的真实表现。


此时一位网友指出:只需要几个简单的优化,比如将 HTTP 客户端与 Redis 实例声明为全局复用、设置合理超时时间、显式捕获异常,Node 的性能就能提升数倍。

而文章中 Go 与 Rust 的实现是高度优化的生产级代码,甚至在某些部分故意忽略错误(如 Redis 获取失败不报错),这本身就构成了比较上的不公平。

测试对比本该是"同一标准",而不是"一个默认值 VS 一个精调系统"


二、Node.js 真的"不行"吗?我们来逐条拆解

  1. 并发模型"落后"?

Node.js 是单线程模型没错,但它采用的是事件驱动 + async/await ****的非阻塞架构,在处理高并发 I/O 时非常高效。

没有线程争抢、没有锁、没有共享内存,一大堆并发 bug 直接被规避掉了。

你不能用 Node 做物理引擎模拟,但它在处理 webhook、 API 转发、日志写入、 BFF 非常合适。


  1. CPU-bound 性能差?

是的,Node 天生不适合处理重计算场景,如图片压缩、大文件加解密。但你真的有这个需求吗?

90% 的 Web 应用都在处理数据库查询、文件上传、表单校验 ------ 这些工作 Node 做得很顺手。

工程实践里,瓶颈常常不在语言,而在 DB 索引没建、缓存策略出错、配置错误拉垮。


  1. npm 生态"不安全"?

npm 被攻击不是因为它"设计不安全",而是因为它是目前体量最大的开源生态,攻击者当然会选它下手。

Go 和 Rust 同样有依赖管理问题。你依赖链足够长,哪种语言都会出事。

合理使用锁版本、自动审计工具(如 Snyk)、发布前 CI 检查,就能把 npm 的"不可控"转化为"可治理"。


  1. 不适合关键系统?

"不能用于关键系统"的观点其实是刻板印象。很多关键业务系统跑的语言远不如 TypeScript 类型强。

Node 的问题不在语言本身,而在用的人。TS + Linter + 架构规范,照样可以跑稳定、高可用的服务。

反倒是那些语言强类型、工具齐全的系统,经常被"写成事故现场",因为开发者高估了语言特性带来的保障。


  1. 部署臃肿、不复现?

这是一个"看起来合理,实际早被解决"的老问题。

Node 的确存在 node_modules 太大的问题,但现代部署环境中已经不再是障碍。使用 PNPM、ESM、Vite 等工具可以显著优化体积。

更重要的是,本地环境不复现、部署环境配置难,是许多开发者日常最大的痛点。

现在我在开发时使用 ServBay ,它能一键集成 Node.js、Redis、PostgreSQL、PHP 等服务,无需写 Docker 配置,也无需安装一堆包,尤其现在已经支持 Windows,非常适合前后端全栈开发者日常使用。


三、那 Go 和 Rust 呢?不是不香,而是代价不小

Rust 几乎是性能天花板,但开发体验真的劝退很多人。

Go 是目前 Web 后端中的"高性价比"方案,但类型系统偏弱,对大型团队依赖规范化。

你要用 Rust/Go 写一个带业务逻辑的 WebSocket Server,也能写,但维护、改需求、上线频率如何?

工程项目不只看 QPS,还得看团队经验、协作效率、上线速度。


四、我们是否对 Node.js 太苛刻了?你真的需要支撑"百万并发"吗?

压测文章虽然有价值,但如果实现方式偏颇,就会误导决策者。

很多时候我们看到的是 Node.js 的"最差用法",却拿它去对比其他语言的"最佳实践"。

但真实世界从不理想化。你写的 Rust 代码,未必就比维护良好的 Node 服务更好用。

对比本身没错,错的是拿错了参照系。

讲句实话,大部分公司根本到不了这个量级。

如果你的网站一天同时在线几千人,Node 足以应对。如果真要承载百万并发,那你不只要换语言,更要换架构、加负载均衡、CDN、分布式集群。

这时候,Go、Rust、甚至 C++ 都是更合适的选择。但别把"异常值"当作常规需求。

合理选型:从业务视角出发

访问量与并发模型

  • 日均并发小于数万:Node.js 完全胜任
  • 并发高于数十万:可考虑 Go,结合 NGINX/Envoy 层做负载分流
  • 超级节点级别(数百万):Rust 或 C++ 更优

功能定位与团队能力

  • 快速 PoC、BFF层:首选 Node.js + TypeScript
  • 核心高并发服务:Go 是首选,Rust 作为底层组件或性能热点优化

运维与成本

  • 容器资源受限:Rust 镜像更小,启动更快
  • 多团队协作:统一 JavaScript 技术栈能降低沟通成本
  • 持续交付:ServBay 等本地环境工具可显著提升开发→测试→生产闭环效率

五、总结:不是语言不行,是你用得不对

Node.js 被批评,其实很多时候是被"误用"。你把它塞进错误场景,还怪它跑不动。

每种语言都有缺陷 ------ Rust 有学习曲线,Go 有类型限制,Node 有性能天花板。但重要的是:有没有合理地发挥它的强项

如果你用 Node.js 做 轻量 BFF、Chat Server,它依然是最佳选择之一。


✅结语:与其争论语言,不如提升判断

技术选型,不该是 Reddit 或 benchmark 上的一句吐槽,而是基于业务目标、团队能力、部署要求的综合权衡。

我们并不需要一个"最强语言",而是要找到一个最适合你项目的工具组合

而在这个组合中,Node.js 仍然有一席之地 ------ 搭配好架构与现代工具,例如 ServBay,它依旧能撑起高效、可靠、好维护的系统。

相关推荐
小王子10249 分钟前
Django+DRF 实战:自定义异常处理流程
后端·django·web开发
考虑考虑12 分钟前
go中的切片
后端·go
天南星1 小时前
java-WebSocket在Java生态中的发展历程
java·后端·websocket
工藤学编程1 小时前
分库分表之实战-sharding-JDBC绑定表配置实战
数据库·分布式·后端·sql·mysql
fmvrj342022 小时前
云原生:数字化转型的核心引擎
后端
码出极致2 小时前
Redisson分布式缓存与数据一致性保障
后端
用户790349033712 小时前
springboot集成redisson实现redis分布式锁
后端
陈随易2 小时前
程序员的新玩具,MoonBit(月兔)编程语言科普
前端·后端·程序员
码出极致2 小时前
Redisson秒杀系统中的分布式锁应用
后端
xiaok2 小时前
@Param注解的作用
java·后端