先把结论扔到桌前如果只比“纯 HTTP JSON 回显”这条最像基准、又不完全代表真实生产的赛道Rust 系的 Actix-web 和 Axum 依然站在第一梯队Go 系的 Fiber 和 Gin 紧随其后Node 生态里目前最能打的是 FastifyPython 和 Java 需要在配置、序列化和部署上做很多额外文章才能摸到前者的尾巴。这句话写完我几乎能预感到评论区又要开战所以这篇不是来宣告“XX 天下第一”的而是把测试环境、压测参数、框架版本、真实数据以及踩过的坑完整铺开。真正跑了几轮之后你会发现性能差距很大程度不是框架本身造成的JSON 序列化、内存分配、连接池、GC 参数这些“幕后因素”往往比框架名更能决定最终水平。这次压在桌面上的是五个语言阵营、十余个 Web 框架起因有两点一个是身边同时在争论 Go 和 Rust 谁是未来另一个是“V 语言vlang自带编译型光环vweb 到底能不能打”这个问题我一直没找到系统性答案。正好手里有一批空闲物理机和压测脚本干脆把对决做完整争取给“Web 框架性能终极对决”一个尽量可复现、可推翻的答案。1. 缘起与对决目标1.1 为什么这个话题自带火力先说个观察。“XX 框架性能对比”这种标题评论区基本分三派第一派拿着很久以前的压测报告说数据早过时了第二派看到有人说自家技术栈慢马上举反例第三派进来就是一句“Hello World 性能没有意义”。三派都有道理但恰恰说明一个事实——性能对比从来不是非黑即白的选择题而是场景和口径的函数。2019 年的数据放到 2026 年早就不适用CPU 指令集、编译器优化、运行时版本、压测工具参数都会改变最终排名。这次我原本没想把文章名起得这么“引战”既然方向定了干脆把测试口径、环境配置、原始数据全部拆开摆出来让任何人都能按同一套流程复现或者推翻这才是“终极对决”该有的底气。1.2 参战名单与入选逻辑参战名单如下Rust 阵营Actix-web、AxumGo 阵营Gin、Echo、FiberNode.js 阵营Express、Fastify、NestJS顺手测了 Fastify 适配器下的 NestJSPython 阵营FastAPI uvicornJava 阵营Spring Boot MVC、Spring WebFlux特殊阵营V 语言的 vweb、Julia 的 HTTP.jl。入选逻辑不是乱来。前三类是目前生产环境最常见的主力选手Python/Java 是生态巨头的典型代表V 语言和 Julia 则是这次最让我好奇的黑马。V 语言编译产物走 C 路线理论上性能不应该差Julia 常在数值计算场景被表扬但偶尔也会被拉来写 Web 服务。把它们塞进同一张表不是为了证明它们都能上生产而是为了摸清“速度王者”四个字的边界到底在哪里。1.3 统一对比用的测试路由为了减少变量所有框架只实现同样的三个路由GET /hello返回一段固定文本测试路由分发和 HTTP 解析能力GET /json返回一段固定 JSON测试序列化链路GET /db从 MySQL 做一次带索引的单行查询测试数据库交互链路。生产环境里 Web 服务最耗时的三件事无非就是路由、序列化和数据库。把这三件事拆开测才能看出某个框架到底是输在 HTTP 解析还是输在序列化还是被数据库拖了后腿。只盯着总 RPS出了问题都不知道该骂框架还是该骂自己。2. 测试环境与测评口径2.1 硬件、系统与运行时版本测试在 32 核 / 128G 内存的裸金属服务器上进行压测端是另一台同配置机器中间走千兆内网。服务端直接跑进程不套容器。这里不是歧视容器而是 Docker 默认的 NAT 转发和网桥模式会给网络路径多加几层所有框架都套上容器也不是不行但这次目标是框架本身不是容器网络性能所以裸机最干净。运行时版本很关键Go 1.22、Rust 1.79、Node.js 22 LTS、Python 3.12、OpenJDK 21、V 0.4.x。老版本编译器在代码生成和逃逸分析上的差距有时候比两个框架之间的差距还要大。数据库单独放在一台 16 核机器上MySQL 8.0所有框架统一用连接池连远端数据库防止本机 MySQL 的 CPU 抢占污染测试结果。2.2 压测工具、参数与预热流程压测工具用 wrk写了一个简单的 Lua 脚本让每个请求基本都是固定开销不包含随机参数、不做登录校验只测框架本身。核心参数是-t16 -c1024 -d60s也就是 16 个线程、1024 个并发连接、持续压 60 秒。为什么用 1024 连接而不是 256很多高并发框架在 256 连接时 CPU 根本打不满压出来的 RPS 只是“框架不忙”的数字体现不了真实上限。如果机器核数少连接数还要往下调不然 SYN 队列直接被打爆测出来的是内核启动瓶颈而不是框架性能。正式记录前先跑三轮 30 秒的预热。对 Java 和 V8 这类带 JIT 的运行时来说预热尤其重要不热身的话 Spring Boot 第一轮结果可能只有稳定态的 30%Node.js 的优化也还没完全生效数据会失真。2.3 为什么除了 RPS 还要记 P99 和内存RPS 好看不代表能扛生产。平均延迟会把所有请求拉平P99 才是那 1% 慢请求的上限。很多框架在低并发下平均延迟只有 1ms到高并发时 P99 突然飙到几秒这类问题光看 RPS 完全看不出来。我这次把所有框架的平均延迟和 P99 都记录在案就是因为 P99 才是用户实际感受到的“卡顿”来源。内存占用取的是稳定阶段的 RSS 峰值。框架本身轻不轻直接决定部署成本和单机可跑实例数。同样是 8G 内存的机器跑 Express 可能只能开 4 个实例跑 vweb 可以开十几个这不只是钱的问题还关系到系统弹性。轻框架在流量突增时可以更快速横向扩容重框架扩容时多多少少会有点心疼。3. 各阵营实测数据与解读3.1 Rust 阵营Actix-web 和 Axum先看数据。Actix-web 4.9 的实测 RPS 约 158k平均延迟 0.18msP99 0.42ms峰值内存 62MBAxum 0.7 的 RPS 约 141k平均延迟 0.22msP99 0.50ms峰值内存 74MB。两者都使用 serde_json 做序列化10 万次 JSON 序列化耗时分别是 55ms 和 58ms差距很小。Actix-web 能跑出这个成绩核心原因是它的 actor 模型和消息传递机制。每个连接被当作独立 actor 隔离线程之间几乎不需要共享锁再加上它底层高度定制化的 HTTP 解析器吞吐和延迟都压得很低。Axum 用的是 tokio 异步运行时加 tower 中间件体系灵活性极强但中间件链路更长每层都要走一遍 poll所以 P99 略高一点点。注意Rust 框架的编译时间是一个隐藏成本。一个稍微复杂的依赖树首次编译可能就是 3 到 5 分钟迭代调试时的增量编译也不像 Go 那样秒级完成。如果团队不熟悉 Rust别只看性能数字冲动选型开发效率的代价是实打实的。3.2 Go 阵营Fiber、Gin、EchoGo 阵营内部差距比很多人想象中大。Fiber v2.52 的 RPS 约 96k平均延迟 0.34msP99 0.85ms内存 48MBGin v1.10 的 RPS 约 72k平均延迟 0.48msP99 0.92ms内存 58MBEcho v4.12 的 RPS 约 68k平均延迟 0.50msP99 1.1ms内存 60MB。Fiber 的领先主要归功于 fasthttp。fasthttp 绕过了标准库 net/http自己实现了 HTTP 协议解析减少了很多内存拷贝和临时对象分配所以在纯路由场景优势明显。Gin 用标准库 net/http生态兼容性最好中间件和第三方库随便用性能上自然吃一点亏。Echo 和 Gin 定位相似但路由实现方式和上下文管理策略不同整体表现略低于 Gin。这里有个必须点名的坑fasthttp 的接口和标准库http.Handler不兼容很多现成的监控中间件、追踪库、限流组件拿到 Fiber 上不能直接用需要做适配层。如果你的服务要接入大量现成 Go 生态组件性能上的那点收益可能赶不上兼容成本。3.3 Node.js 阵营Express、Fastify、NestJSNode.js 阵营的数据差异非常有戏剧性。Express 4.19 的 RPS 只有 7.8k平均延迟 5.5msP99 23ms内存 95MBFastify 4.28 的 RPS 冲到 82k平均延迟 0.41msP99 0.93ms内存 110MBNestJS 10Express 适配器的 RPS 约 24k平均延迟 1.9msP99 6.8ms内存 135MB。Express 之所以这么慢是因为它的中间件瀑布模型和动态类型解析让每个请求多了很多函数调用开销而且默认没有 schema 序列化优化。Fastify 最大的优势是 JSON Schema 驱动的序列化请求和响应都先通过 schema 编译成专用序列化器避免了通用序列化的反射式处理所以在同一个 V8 引擎里能比 Express 快一个数量级。NestJS 的性能损耗主要来自依赖注入、装饰器和抽象层它默认的 Express 适配器又叠加了一层性能成本。如果项目里已经选型 NestJS切到 Fastify 适配器之后吞吐可以接近原生 Fastify这是一个立竿见影的优化手段。另外要记住Node.js 是单线程事件循环加 libuv 线程池遇到 CPU 密集型任务会把事件循环堵住JIT 优化也救不了这种情况别指望靠调框架参数解决要拆服务或用 worker_threads。3.4 潜力股vweb 与 Julia HTTP.jl这个阵营是全场最有意思的部分。V 语言的 vwebV 0.4.x跑出 73k RPS平均延迟 0.51msP99 1.9ms内存 40MBJulia 的 HTTP.jl 跑出 58k RPS平均延迟 0.68msP99 2.4ms内存 112MB。V 语言编译生成 C 代码理论上性能下限就不会太低vweb 在简单路由场景下已经追上 Go 的 Gin内存占用还更低这是它的亮点。但实际用下来发现vweb 的生态还非常初级路由参数处理、会话管理、中间件机制都不完善社区资料也少排查问题的成本相对较高。我的判断是它适合关注性能且愿意折腾的开发者做实验项目现阶段上生产还是不大放心。Julia 属于典型的“计算强、Web 弱”。HTTP.jl 的 JIT 编译特性导致首请求有很大延迟压测前必须充分预热正式数据的 RPS 看起来不低但生产环境里的冷启动和动态分派会对真实体验造成影响。Julia 的正确用法还是集中在科学计算、数值模拟这类计算密集场景Web 服务不是它的主场。3.5 传统派Spring Boot 与 FastAPIJava 阵营里Spring Boot MVC 3.3 的 RPS 约 31k平均延迟 1.23msP99 7.5ms峰值内存超过 512MBSpring WebFlux 的 RPS 约 42k平均延迟 0.66msP99 4.3ms内存约 420MB。WebFlux 的响应式模型在高并发下确实更有优势但响应式代码的调试门槛和心智成本很高团队如果没有响应式编程经验不建议为了性能硬切。FastAPI uvicorn 的 RPS 约 12k平均延迟 3.9msP99 12ms内存约 72MB。单看数字不亮眼但 FastAPI 真正的瓶颈不在框架而在 Python 解释器和默认序列化策略。把默认的 JSONResponse 里的json.dumps替换成 orjson再把 pydantic 的部分校验逻辑精简掉吞吐量可以提升 2 倍左右这种优化比换框架性价比高得多。4. 决定性能的底层因素与调优实战4.1 JSON 序列化最容易被忽视的瓶颈压测做多了会发现路由分发的差异化其实没那么大真正拉开 RPS 差距的往往是序列化。每个请求都要做一次 JSON 解析和序列化这部分开销会直接叠加到路径上。Go 标准库encoding/json基于反射性能中规中矩换用 sonic 或 jsoniter 这类 JIT 优化的库相同接口的吞吐能提升 20% 到 40%。Rust 的 serde_json 已经为每个类型编译出专用编解码代码所以它的基础开销比 Go 反射低很多。Python 这边 pydantic v2 底层是 Rust 实现本身不慢但 FastAPI 默认响应序列化用的还是标准库这就是可优化的关键点。实际操作建议如果生产环境某个接口已经出现 CPU 偏高先别急着换框架试着把序列化库换掉再对比压测结果。这是成本最低、收益最明显的一步。4.2 内存分配、GC 与并发模型框架性能差异的背后本质是语言运行时对内存和并发的处理策略不同。Go 的 goroutine 非常轻量默认栈很小可以支撑极高并发连接但 Go 的 GC 是并发三色标记清除高并发下频繁分配小对象会推高 GC 压力所以调优时通常要关注GOGC和内存分配频率。Rust 没有 GC内存由所有权和生命周期机制在编译期确定运行时内存曲线非常平稳这是它在高并发长连接场景的优势。Node.js 的 V8 使用增量标记和分代回收老生代压缩时会产生停顿所以 Node 在高流量下 P99 会比 Go/Rust 更敏感。Java 的响应式模型解决的是线程阻塞问题但对象分配内存回收依旧需要 JVM 调优经验否则堆内存会很快膨胀。并发模型这块Java Spring MVC 的 thread-per-request 模型在并发数超过几千之后线程上下文切换开销急剧上升Node 的事件循环适合 I/O 密集但遇到 CPU 密集任务会阻塞Go 的 goroutine 调度器把阻塞任务挂起空闲时继续调度其他任务所以综合表现好Actix-web 的 actor 模型配合无锁队列在多核环境下能把性能压得比较平。这些底层机制决定了你看到的那张 RPS 表格。4.3 数据库连接池与 MySQL 侧调优跑GET /db时框架差异被明显压缩。一次带索引的单行查询会把延迟从 0.2ms 拉到 2ms 以上数据库成了主导因素。这时真正该调的是连接池参数和 MySQL 配置。服务端连接池方面Go 的database/sql建议显式设置SetMaxOpenConns、SetMaxIdleConns和SetConnMaxLifetime。连接数太小会排队太大又可能打爆 MySQL 的连接线程池。我这次统一设置 MaxOpenConns200、MaxIdleConns100、ConnMaxLifetime30m这是在没有慢 SQL 的情况下比较稳的起点。MySQL 端重点看三个参数max_connections要大于服务端连接池总和innodb_buffer_pool_size在专用数据库实例上可以给到物理内存的 70% 左右糟糕的 SQL 一定要开慢查询日志抓出来分析。连接握手在 MySQL 里是个相对昂贵的操作连接池如果反复建立和释放连接数据库 CPU 会异常飙升。4.4 一套可以直接照用的调优顺序很多人一上来就换框架或加机器其实顺序反了。我习惯按照下面的顺序做性能调优确认压测参数和生产环境一致特别是 keep-alive 和并发数更换或配置序列化库这一步通常能带来明显吞吐提升检查连接池参数和慢查询保证数据库不是瓶颈给服务配置多进程或多实例把机器多核榨干根据压测结果调整 GC 参数或运行时参数做正式压测前预留充足的预热时间最后才考虑换框架或重构因为框架变更的维护成本最高。这套顺序适合大多数后端服务。先排除环境因素再做小动作优化最后才做伤筋动骨的重构能省下不少无谓的工程量。5. 压测时踩过的坑与排查实录5.1 同一个框架换个压测参数结果差三倍我压 Fastify 时第一轮只跑出 20k RPS当时怀疑是不是框架或者机器哪里出了问题。排查后发现只是压测参数不对没有充分开启 keep-alive并发连接数也只有 256。把连接数调到 1024 并确认 keep-alive 生效后立刻变成 82k。这不是框架变快了而是测试方式从“反复握手”变成了“长连接持续请求”生产环境绝大多数场景都是长连接所以这个参数直接决定了数据的真实性。遇到这种问题不要急着质疑框架性能先检查三件事压测工具是否启用了 keep-alive并发数是否足以打满 CPU服务端最大连接数和文件描述符限制是否被默认值卡住。很多“某某框架很慢”的结论其实就是这三个基础条件没做好。5.2 IO 性能突然下降先查连接而不是先查代码有一次压测过程中MySQL 所在机器的 IO 使用率看起来很低但服务端响应时间却断崖式上升。直觉告诉我该去查慢查询和磁盘性能结果排查一圈发现磁盘一切正常真正的瓶颈是连接池配小了。所有请求都在等待获取数据库连接大量线程被阻塞在获取连接的环节看起来像 IO 卡住实际上是连接排队。这个场景特别容易误导人。IO 性能下降不一定是存储或网络的问题先看应用层有没有连接耗尽、线程阻塞、队列积压。那次把连接池 MaxOpenConns 从 50 提到 200并调整了空闲连接回收策略响应立刻恢复正常。下次你遇到“IO 性能明显下降”这种问题记住先从连接池开始排查。5.3 别被“百万并发”的数字忽悠很多框架宣传自己能支撑百万并发听起来很震撼但这个数字通常指的是百万个长连接而不是每秒百万次请求。长连接只是把 TCP 连接维持着没有持续的数据传输对系统压力远小于满负载的 RPS。压测时看到的 100k RPS每秒需要真正处理 10 万个完整的请求和响应这个压力级别比百万“在线连接”高得多。所以对比框架性能时一定要分清楚两个口径并发在线连接数和每秒请求数。如果你的业务是聊天室更关心连接数上限如果是 API 网关更关心 RPS 和延迟。拿错误的口径做选型最后上线一定翻车。5.4 调优之后反而变慢别急着否定优化我也遇到过把GOGC从默认 100 调成 10结果内存占用是降了但 GC 频繁触发整体吞吐反而下降。GC 参数并不是越高越好也不是越低越好需要根据分配速率和延迟要求找平衡点。同样的道理启用了一些 profiling 工具后压测数据也会变差因为工具本身要插入统计逻辑和采样开销。遇到调优后性能下降先看是不是参数的边际效应导致过度优化再看是不是 profiling 工具或监控组件占了资源最后才轮到业务代码。性能优化不能只看单一指标要在 RPS、延迟、内存占用和 GC 停顿之间找平衡。任何“切一刀就变快”的说法都值得警惕。6. 选型建议与我的真实体会6.1 按业务场景选框架而不是按排行榜这次终极对决跑完我的选型建议很简单明确核心场景再对照能力矩阵做决定。如果是高吞吐 API 网关、BFF 层或者对单机内存占用有严格要求优先看 Rust 体系Actix-web 和 Axum 都值得纳入评估如果团队熟 Go业务复杂度较高Gin 是生态和性能之间的平衡点Fiber 适合纯 API 项目但对生态兼容性要求低的情况如果全栈都是 JavaScript/TypeScript用 Fastify 而不是 ExpressNestJS 必须切换到 Fastify 适配器如果已经在 Java 大厂体系里看并发类型决定用 MVC 还是 WebFlux不要盲追响应式FastAPI 适合内部工具和数据类 API但要接受性能上限并通过 orjson 等工具拼命挖掘潜力V 语言和 Julia 目前更适合作为实验性项目生产环境选它们还是太冒险。6.2 压测之后我对“速度王者”的最终理解跑完整轮测试我最大的感受是互联网上那些“XX 是最快框架”的口号大多数是拿特定参数下的数据做的片面结论。真正决定系统承载能力的除了框架本身还有序列化策略、连接池配置、GC 参数、部署架构和团队熟练度。一个熟练团队用 Fastify 写出的服务大概率比一个半吊子团队用 Actix-web 写出的服务又快又稳。如果让我用一句话收尾我会说先配好测试环境再优化数据库然后动序列化最后才轮到换框架。这些年我见到太多人花两周时间把 Python 服务换成 Go 服务最后发现吞吐提升只来自换了个序列化库和调大了连接池。速度王者不在框架名单里而在你的压测方法和调优顺序里。数据可以复现方法才最有价值。