后端框架选型：别只看 QPS 排行榜，你其实是在选『愿意忍哪个坑』

2019 年我在一家做 SaaS 的公司，团队把一个跑了三年的 Django 单体拆成 FastAPI 加若干微服务。理由很充分：接口 P99 卡在 800ms 下不去。拆完之后 QPS 确实上去了，P99 掉到 120ms 左右。但半年后复盘的时候我们发现，那 800ms 里有 600ms 是三个 N+1 查询和一个没加索引的模糊匹配，跟框架一点关系都没有。更讽刺的是，换成 FastAPI 之后我们新写了大概四千行异步代码，其中真正需要并发的不到 10%，剩下的纯粹是因为你在 async 函数里碰同步 ORM 会直接抛错，只能被迫一路 async 下去。那次之后我换了个角度看选型这件事。大部分人做的是一张评分表：性能、生态、学习曲线、社区活跃度，各打几分加权。我现在认为这张表基本没用，因为它是可替代的——换个语言、加两台机器、招个更贵的人，这些分都能补回来。真正决定一个项目三年后活得舒不舒服的，是这个框架最烂的那一块，以及你的业务会不会天天撞上它。

Spring Boot 的坑是『启动税加上魔法不可见』。一个带了 JPA、Security、Actuator 的中等规模项目，在我那台 8C16G 的开发机上冷启动大概 11 秒，打成 jar 跑 6 到 8 秒，丢进 K8s 叠上镜像拉取经常摸到 30 秒。常驻堆 400MB 起步。GraalVM native image 能把启动压到 100ms 以内、RSS 压到 60MB 上下，但代价是反射配置、@ConfigurationProperties 的代理、以及一堆库根本不支持 AOT——我试过一次，光是为了让一个自定义 Jackson 反序列化器活下来就写了三十行 RuntimeHintsRegistrar。另一个高频坑是 AOP，@Transactional 自调用失效这件事，我在不同公司见过至少五拨人踩。所以问题不是『Spring Boot 好不好』，而是你的业务是不是那种『十几个内部接口，一天几万次调用』的规模——如果是，你其实不需要它，但你八成还是会用它，因为 Java 的人好招。

Django 的坑是 ORM 绑架加上异步半残。Django 从 4.1 开始有了 aget、acreate 这类异步查询方法，5.0 补上了 asave、adelete，看着挺齐。但你在 async view 里直接写 Model.objects.filter() 依然会吃到 SynchronousOnlyOperation，得套 sync_to_async，而它的 thread_sensitive=True 到底走哪个线程池、边界在哪，我第一次是翻源码才看明白的。select_related 跨关系、复杂 annotate 聚合这些，异步支持到现在也不齐。反过来说，Django Admin 这个东西的价值被严重低估了。我在两家公司见过运营后台直接用 Admin 改吧改吧用了一年半，省下至少两个前端人力。所以它属于『技术债你有感知，但收益你也有感知』的类型，比那种纯负债的框架好判断。

FastAPI 的坑是『生态碎片化加上版本地狱』。Pydantic v1 到 v2 那次迁移，validator 变 field_validator，Config 类变 model_config = ConfigDict(...)，orm_mode 变 from_attributes，parse_obj 变 model_validate。表面上是改名字，但 v1 的 validator(always=True) 和 v2 的 model_validator(mode='before') 语义并不完全对齐。我见过一个校验逻辑迁移之后行为静默变了——不再抛异常，而是返回 None，然后一路写进数据库。SQLAlchemy 1.4 到 2.0 又是一轮，session.query().filter() 那套被标了 legacy，得换成 select()。关键在于，FastAPI 本身很薄，薄到你会发现你选它其实是在选 Starlette 加 Pydantic 加 SQLAlchemy 加 Alembic 这一整串，每个都得你自己盯着它的 release note。

Go 那边，不管是 Gin、Echo 还是 Fiber，坑是『样板代码和错误处理纯体力活』。if err != nil { return err } 这个模式，我在一个中等项目里粗略数过，平均每 40 行出现一次。好处是代码永远一眼看得懂在干嘛，坏处是你也永远写不快。另外 Gin 的 *gin.Context 不是 context.Context，两套取消机制并存，这东西坑过不少人，包括我——有一次超时没传到 DB 层，连接池直接被打满，排查了一个下午。NestJS 的坑是抽象层数太多：装饰器、DI、模块、拦截器、管道、守卫，一个请求要穿过六层。规范是真规范，但 debug 的时候 stack trace 里四十行是框架自己的。再加上 Node 单线程在 CPU 密集场景的硬伤，worker_threads 能绕，但绕的方案复杂度足够让你怀疑当初为什么不直接上 Go。

上面说的这些，我想表达的核心观点是：后端框架的真实成本从来不是性能，是升级税和接盘半径这两样东西。升级税指的是一个框架每年逼你花多少工时在『为了升级而升级』上。Spring Boot 2.7 到 3.x 那次 javax 到 jakarta 的迁移，我经手过一个十二万行的项目，前后花了大概三周，其中两天全耗在一个老旧的 SOAP 客户端库上——它还在用 javax.xml.bind，而 JDK 11 之后这东西已经从标准库里移出去了。这个税你没法不交，因为不升级就拿不到安全补丁。评估方法很土但有效：翻这个框架最近三个大版本的 changelog，数 breaking change 的条数，再看你依赖的那几个生态库平均隔多久跟进。接盘半径指的是假设明天你团队全离职，市场上招一个人，他多久敢改你的核心代码。这个指标比『学习曲线』具体得多。Java 和 Spring 大概 1 到 2 周，Python 和 Django 差不多，Go 1 到 3 天，因为语言本身小、代码基本都是直白的判断。Rust 的 Axum 或者 Actix-web 我给不出一个诚实的数字——我自己写 Rust 写了两年，接手别人的 async Rust 依然会卡在生命周期和 Pin 上。

如果你现在正好在做选型，我建议别做那张评分表，改成跑下面这几步。第一步，把你业务里最复杂那个查询拎出来，在候选框架里各写一遍，不看 QPS，看行数和你能不能一眼读懂，超过六十行还没收尾的直接扣分。第二步，数清楚你的业务里事务边界平均跨几张表，跨三张以上，Spring 的 @Transactional 和 Django 的 atomic() 能救你；如果只是单表 CRUD，Go 那边手写 BEGIN / COMMIT 也完全够。第三步，算升级税：翻三个大版本的 changelog，把 breaking change 条数乘以你团队的人天单价，得出来的数字可能比服务器账单还吓人。第四步，测冷启动：本地跑二十次取中位数，Spring Boot 的 jar 是 6 到 8 秒，Go 的二进制 50ms 以内，Node 1 到 2 秒，FastAPI 加 uvicorn 大概 0.5 到 1 秒；如果你的部署方式是 K8s 上频繁扩缩容、流量有十倍波峰，这一项权重直接拉满。最后一步是我个人认为最有用的：问自己『如果这个框架三年后停止维护，我能不能在两个月内把它换掉』。能，就选它；不能，那你选的是婚姻，不是技术栈。