网上最近热传的一篇文章《我们向 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，它依旧能撑起高效、可靠、好维护的系统。