后端框架选型：Fastify / FastAPI / Spring Boot / Go 怎么选？

Tue, 30 Jun 2026 00:00:00 +0000

我在为一个小型信息管理 Web 项目做后端选型，候选有 Node.js (Fastify)、Python (FastAPI)、Java (Spring Boot)、Go (Gin)。为了不被"听说"带节奏，我读了两篇风格迥异的性能对比文章，把结论提炼出来，并给出针对这类项目的明确推荐。

先说结论：对小型信息管理系统，我会首选 Python (FastAPI)；如果团队是 JS/TS 背景，选 Fastify；只有当你在意单二进制部署或预期流量会快速增长时，才需要认真考虑 Go (Gin)。Spring Boot 对这个量级偏重，除非你本来就是 Java 栈。下面是依据。

一、第一篇：Travis Luong 的单机 wrk 基准测试

来源：FastAPI vs Fastify vs Spring Boot vs Gin Benchmark

这篇是相对"实验室"式的测试：每个框架写一个接口，从 PostgreSQL 查 100 行数据返回 JSON，用 wrk 压 10 秒。作者非常坦诚，多次更新修正了"进程数不对等"等测试缺陷。它的价值不在于绝对数字，而在于揭示了配置对性能的放大效应。

代表性排名（req/sec，摘自作者的最终榜单）：

排名	配置	req/sec
1	Spring Boot + jdbc（原生）	7886
2	Go + pgx	7517
3	Go + pg + 连接池调优	7388
4	FastAPI + asyncpg + ujson + gunicorn 8w	4831
5	Fastify + pg + cluster 8w（关日志）	4622
8	Express + pg + cluster 8w	4145
10	Gin + database/sql + lib/pq	2966
12	Fastify + pg（单进程）	2184
20	Spring Boot + JPA（ORM）	844

作者自己提炼的几点，比排名本身更值得记：

FastAPI 开箱并不快——必须配上 asyncpg 异步驱动才能发挥，光这一点就能拉开数倍差距。
即使用了 asyncpg，还要换更快的 JSON 库（orjson/ujson） 才能追上 Node.js。
原生 SQL 转 JSON 远快于 ORM——最直观的证据：同样是 Spring Boot，用 jdbc 是 7886，换成 JPA 直接掉到 844，差了近 10 倍。框架的"慢"往往来自 ORM 层，而不是框架本身。
编译型语言（Java/Go）在同等配置下确实比解释型快。
日志会拖性能——Fastify 关掉日志后明显提速。

一句话总结：这篇告诉我们"配置 > 选型"——同一个框架，会不会调，性能能差一个数量级。

二、第二篇：10 亿请求下的"生存测试"

来源：五大主流 Web 框架真实性能对比：10 亿请求下谁能幸存？

这篇更"生产化"：谷歌云 4 核 16G、Docker 部署、PostgreSQL 连接池，用 wrk2 把流量从 100 RPS 一路爬到 10 万 RPS，同时观察吞吐、延迟、内存、CPU、错误率。

核心数据：

框架	持续稳定 RPS	峰值内存	99% 延迟	CPU 峰值	错误率(10万RPS)
Rust (Actix-Web)	110,000	250 MB	7 ms	75%	0.01%
Go (Gin)	105,000	190 MB	10 ms	68%	0.03%
Node.js (Fastify)	60,000	650 MB	35 ms	82%	0.5%
Java (Spring Boot)	40,000	1.4 GB	50 ms	88%	0.3%
Python (FastAPI)	8,000	1.2 GB	150 ms	100%	15%

作者的"幸存者"分级：

绝对幸存者 —— Go (Gin)：性能、开发效率、生态三者最平衡，像"AK47"，易上手、耐造。
极限生存者 —— Rust (Actix)：性能天花板，但学习曲线陡，需专业团队。
主流生存者 —— Fastify / Spring Boot：覆盖大多数公司的常规战场。
限定生存者 —— FastAPI：仅在低并发"安全区"（< 1 万 RPS）表现良好，适合数据管道、AI 模型接口。

一句话总结：这篇把极限高并发的天花板拉了出来——系统级语言（Go/Rust）是降维打击，但前提是你真的有那么多流量。

三、两篇放在一起看

两篇文章结论高度一致，但视角互补：

性能天花板：Go ≈ Java(原生) > Node > Python。压到极限时，编译型语言的优势会随并发上升而放大。
资源效率：Go 最省（190MB），Java 最重（1.4GB + 启动 12 秒）。Python 在高并发下反而吃内存（1.2GB）且错误率飙升。
易用性 / 开发效率：恰好与性能排序相反——FastAPI 开发最快、自动文档最香，但抗并发最弱。

关键陷阱：别把高并发结论直接套到小项目上。 第二篇自己也写明，FastAPI 的"安全区"是 < 1 万 RPS——而一个小型信息管理系统，日常峰值大概率在几十到几百 RPS，离这个阈值有两个数量级。在这种流量下，框架本身的吞吐根本不是瓶颈，开发速度、可维护性、文档自动生成才是。

四、针对"小型信息管理系统"的推荐

信息管理系统的典型特征：以 CRUD 为主、中低并发、前后端分离、追求快速交付。这类项目的真正成本不在服务器，而在开发和对接的人力。所以选型权重应该是：开发效率 > 文档/对接 > 部署运维 > 极限性能。

按这个权重，决策如下：

你的情况	推荐	理由
想最快交付、要自动 API 文档给前端	FastAPI	类型提示 + 自动 OpenAPI 文档，信息管理系统的 CRUD 接口几乎"写模型即得文档"；<1万 RPS 安全区绰绰有余
团队是 JS/TS 背景，想前后端同语言	Fastify	比 Express 快、schema 校验内置，前后端类型可复用
追求单二进制部署、运维简单，或预期流量会涨	Go (Gin)	编译成一个可执行文件扔服务器即可，无运行时依赖；两篇文章里都是"绝对幸存者"，未来不会遇到性能墙
已有 Java 栈 / 复杂事务和权限	Spring Boot	生态最全，但启动慢、内存重，对小项目是"用航母运快递"

我的最终选择是 FastAPI。原因很实在：信息管理系统的价值在于"把数据管起来、把接口暴露清楚"，FastAPI 的 Pydantic 模型 + 自动文档把这两件事的成本压到了最低；性能上配 asyncpg + orjson（第一篇验证可到 ~4800 req/s）对小型系统完全是冗余的富余。等哪天流量真涨上来，再按第二篇的指引用 Go 重写核心接口，成本也可控——技术选型从来不是非黑即白，而是匹配当下的战场。

参考来源：

Travis Luong — FastAPI vs Fastify vs Spring Boot vs Gin Benchmark
51CTO — 五大主流 Web 框架真实性能对比：10 亿请求下谁能幸存？

技术选型 on 武成龙

后端框架选型：Fastify / FastAPI / Spring Boot / Go 怎么选？

一、第一篇：Travis Luong 的单机 wrk 基准测试

二、第二篇：10 亿请求下的"生存测试"

三、两篇放在一起看

四、针对"小型信息管理系统"的推荐