后端框架选型别只盯着性能榜：我踩过 Spring Boot 3 的坑之后，开始看「大版本升级成本」这个指标
2023 年 11 月，我把手上一个 4 年历史的 Spring Boot 2.3 项目往 3.2 上推。第一天改完 javax.servlet 到 jakarta.servlet 的 import，项目里 200 多个文件飘红。第二天发现 WebSecurityConfigurerAdapter 在 Spring Security 6.0 里已经彻底删了，得重写成 SecurityFilterChain bean 的写法，我们那套写了三年的自定义过滤器链基本作废，连带 AuthenticationManager 的注入方式也变了。第三天为了对齐 Java 17 去调 docker-compose 里的基础镜像，结果 MySQL 8 的 caching_sha2_password 又跟老的 JDBC 驱动打架。第四天早上我把分支 revert 了，在 2.7 上又苟了半年。
那次之后我改了一个判断标准：评估一个后端框架，我会先去看它 CHANGELOG 里破坏性变更的密度，而不是看基准测试的 RPS 数字。 这个标准听起来不太性感，但它救过我不止一次。
性能榜的信噪比，比你想的低得多
TechEmpower 那套基准测试我看了好几年，Plaintext 和 JSON 序列化这两个场景里，头部框架和尾部框架能差出两个数量级以上。Go 系裸写 http 的那几个、加上 FastHTTP，常年霸榜；Spring WebFlux 夹在中间；Django 配 gunicorn 同步 worker 基本属于垫底那一档。看榜单的第一反应是「那我用 Go 啊」，但真实业务跑起来完全不是这么回事。
我自己压过一个订单查询接口，生产环境 QPS 顶到 800 左右就上不去了。我当时以为是框架的锅，换了个路由实现重新压，还是 800。后来 explain 一把才发现是 user 表上有个查询没走索引，全表扫 40 万行。加完索引直接到 2600。框架路由那点开销，在真实业务里大概占总耗时的 2% 到 5%，剩下 95% 全在你自己的 SQL、序列化和 IO 上。 除非你做的是网关或者长连接推送，否则性能榜的边际收益非常低。
我提出的模型：升级成本 ≈ 横向耦合层数 × 各层发版节奏差
这是我自己的一个粗模型，不一定严谨，但用来做技术决策挺好使。一个框架在你运行时链路里横向耦合几层，每层的主版本发布节奏差别有多大，决定了你未来三年会不会被一次升级拖住两周。
Gin 这一档：耦合层数约等于 1。 Go 标准库 http 加一个 Gin 包，就到头了。gin.Context 的核心 API 从 v1.0 到现在基本没动过，v1.9 到 v1.10 那次我升完业务代码一行没改，只是 go.mod 里几个 golang.org/x/net 的版本被带了一下。Go 社区还有个 v2 模块路径的约定，真要打破兼容就得改 import 路径，反而在编译期就拦住了。
Express 这一档：耦合层数约等于 3，但各层节奏混乱。 Node 本身、Express 本体、再加一整片中间件森林（body-parser、helmet、cors、passport、multer）。Express 4 到 5 拖了将近十年，2024 年 9 月才正式发 5.0。它把 path-to-regexp 升到 8.x，导致 * 通配符必须写成 *splat 或者 /{*splat}，res.send(404) 这种写法不再顺带设置状态码，正则路由的语法也变了。单条改动都不难，麻烦的是 @types/express 这类 DefinitelyTyped 包跟主包不同步，你会有一段时间在类型报错里挣扎。
FastAPI 这一档：耦合层数约等于 4，但有过一次「核弹级」迁移。 Python 版本、FastAPI、Starlette、Pydantic，四层。0.100 那次把 Pydantic v1 和 v2 的兼容层拆开，同时 @app.on_event("startup") 被弃用改推 lifespan context。如果你用了 pydantic.BaseSettings，v2 里它被移到独立的 pydantic-settings 包里，import 路径全变，class Config 要改成 model_config = SettingsConfigDict(...)，@validator 改成 @field_validator。我在一个三万多行的项目上做过这次迁移，改了一百五六十处，花了两天，其中一半时间是在处理嵌套 model 的序列化行为差异——v1 和 v2 对 Optional 字段和 datetime 的默认处理是真的不一样。
Spring Boot 这一档：耦合层数 6 到 8 层。 Java 本身、Spring Boot、Spring Cloud、一堆 starter、Jakarta EE 规范、JVM。2.7 到 3.0 那次迁移是史无前例的：整个 javax.* 命名空间要换成 jakarta.*，这不是加个依赖能解决的，是同一套 API 换了包名。Spring 官方那份 3.0 Migration Guide 我数过，独立的迁移条目有三十多条，而且很多条目之间有先后依赖——你得先让项目在 Java 17 下编译通过，再处理 Jakarta 命名空间，再动 Security 配置，最后才轮得到 Actuator 端点路径的变更。顺序错了会一直卡在一些莫名其妙的 NoClassDefFoundError 上。
反直觉的地方：越「一体化」的框架，破坏性变更来得越猛
按理说框架帮你干的事越多，你写的代码越少，升级应该越轻松。实际观察下来是反的。原因也不复杂：帮你干的事多，意味着它内部有更多层在互相耦合，一次主版本变更往往会同时触碰好几个层面。Spring Boot 3.0 就是典型，它没有只改一件事，而是一次性改了命名空间、最低 Java 版本、Security 配置模型和可观测性端点四个层面。
但 Django 是个漂亮的例外，也恰好证明了规则的另一半：升级成本不只取决于耦合层数，还取决于维护方对弃用周期的执行力。 Django 的 deprecation 政策是把废弃警告提前整整两个大版本写进 release note。django.conf.urls.url() 在 2.0 就标记废弃，一直到 4.0 才真正移除；ugettext_lazy 在 3.0 废弃，4.0 才移除。中间你有接近两年的窗口期，而且跑测试的时候 RemovedInDjango40Warning 会主动跳出来提醒你。这种做法把「一次痛苦的迁移」摊平成「两年里零散修几十处」，主观感受完全不一样。
Spring 其实也有 @Deprecated 和 forRemoval，但它的工程实践里缺了一环：跨大版本时经常一步到位地删，WebSecurityConfigurerAdapter 从标记弃用（5.7）到移除（6.0）只隔了一个小版本周期。
如果你现在正在选框架，我会按这四步走
第一步，数一下你的代码有多少处依赖框架的内部 API。 不是公开文档里写的那种，是 org.springframework.beans.factory.support 这种包下面的类，或者从 django.db.models.sql 里 import 东西。超过 5 处，你实际上没有换框架的能力，那选型时就更该看重升级平滑度，而不是性能。
第二步，把候选框架近三个大版本的 Backwards Incompatible Changes 章节拉出来数条目。 Django 4.2 的这份清单大概二十条上下，而且绝大多数带着明确的替代写法；Spring Boot 3.0 的迁移指南三十多条且互相有依赖顺序。数字本身不重要，重要的是看看修复成本是「替换函数名」还是「重写模块结构」。
第三步，拿真实业务里最复杂的那张表跑一遍最小闭环。 不是 hello world。我一般会写这么四个接口：单表 CRUD、带事务的批量写（至少 1000 条）、带查询条件分页的列表、一个带缓存穿透保护的单条查询。三个星期内用候选框架各写一遍，你会在第三天就摸到这个框架的脾气。
第四步，估算回滚成本。 新框架上线出问题，你能不能在一小时内切回去？如果灰度方案里回滚要改数据库 schema 或者要重放消息队列，那这个框架再好也别急着上。
2024 到 2025 年我自己的结论
团队 3 到 5 个人做业务型 SaaS，我倾向 Django + DRF 或者 FastAPI。不是因为性能，是因为出问题时你能一路读框架源码读下去，Python 的动态特性能让你在 pdb 里直接看到调用栈全貌，而且升级路径可预测。
做高并发网关、中间件、对部署体积和内存占用敏感的服务，用 Gin。静态编译和模块路径的兼容约定基本让你不会遇到「升不上去」这种体验，交叉编译丢一个二进制到容器里就跑，运维成本也低。
大企业已经在 Spring 生态里，别为了升级而升级。除非你有明确的诉求要上 Java 21 的虚拟线程（Loom），那个确实值得为它付一次迁移成本，前提是你的业务真的是 IO 阻塞密集型，而不是 CPU 密集型。CPU 密集的事虚拟线程帮不了你。
个人偏见：我现在接新项目，除非有硬性的 Java 生态依赖（比如必须对接公司内部一堆 Java SDK 和 Kafka 的定制客户端），我基本不会再选 Spring Boot 作为起点。这个判断不客观，纯属被那次四天的迁移经历教育出来的。