网上最近热传的一篇文章《我们向 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 真的"不行"吗?我们来逐条拆解
- 并发模型"落后"?
Node.js 是单线程模型没错,但它采用的是事件驱动 + async/await ****的非阻塞架构,在处理高并发 I/O 时非常高效。
没有线程争抢、没有锁、没有共享内存,一大堆并发 bug 直接被规避掉了。
你不能用 Node 做物理引擎模拟,但它在处理 webhook、 API 转发、日志写入、 BFF 层非常合适。
- CPU-bound 性能差?
是的,Node 天生不适合处理重计算场景,如图片压缩、大文件加解密。但你真的有这个需求吗?
90% 的 Web 应用都在处理数据库查询、文件上传、表单校验 ------ 这些工作 Node 做得很顺手。
工程实践里,瓶颈常常不在语言,而在 DB 索引没建、缓存策略出错、配置错误拉垮。
- npm 生态"不安全"?
npm 被攻击不是因为它"设计不安全",而是因为它是目前体量最大的开源生态,攻击者当然会选它下手。
Go 和 Rust 同样有依赖管理问题。你依赖链足够长,哪种语言都会出事。
合理使用锁版本、自动审计工具(如 Snyk)、发布前 CI 检查,就能把 npm 的"不可控"转化为"可治理"。
- 不适合关键系统?
"不能用于关键系统"的观点其实是刻板印象。很多关键业务系统跑的语言远不如 TypeScript 类型强。
Node 的问题不在语言本身,而在用的人。TS + Linter + 架构规范,照样可以跑稳定、高可用的服务。
反倒是那些语言强类型、工具齐全的系统,经常被"写成事故现场",因为开发者高估了语言特性带来的保障。
- 部署臃肿、不复现?
这是一个"看起来合理,实际早被解决"的老问题。
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,它依旧能撑起高效、可靠、好维护的系统。