如果你维护着一个Spring Boot 3.x的项目，现在是时候认真规划4.0升级了。
Spring Boot 4.0标志着Java企业级开发的代际切换：Spring Framework 7.0、Jakarta EE 11、Servlet 6.1、Tomcat 11、Jackson 3.x、Hibernate 7.1……几乎每一层核心依赖都完成了大版本跃迁。
这不是一个小版本号的变更，而是一次结构性换代。
一、平台基线升级：全面切换到下一代标准
先看核心依赖的版本对照表——每一个数字变化背后都意味着API调整：
| 组件 | Boot 3.x | Boot 4.0 | 变化影响 |
|---|---|---|---|
| Spring Framework | 6.x | 7.0.x | 核心框架API调整 |
| Servlet / Jakarta EE | 6.0 / 10 | 6.1 / 11 | 所有jakarta.*依赖需升级 |
| 内嵌Tomcat | 10.x | 11.x | Servlet 6.1适配 |
| 内嵌Jetty | 11.x | 12.1 | 同步升级 |
| Jackson | 2.x | 3.x | JSON序列化行为可能变化 |
| Hibernate | 6.x | 7.1 | ORM配置与方言调整 |
| Spring Data | 旧版 | 2026 | 查询API可能变化 |
| Spring Batch | 5.x | 6.0 | 批处理配置调整 |
重点警告：所有与jakarta.*、Servlet API、容器适配相关的依赖必须升级到兼容Servlet 6.1的版本。如果你使用了第三方Servlet Filter或Listener，需要确认其兼容性。
二、Web生态大换血：Undertow被移除
这是4.0中最"激进"的变更——Undertow彻底从Spring Boot中移除，原因是Undertow不支持Servlet 6.1。
2.1 Starter结构调整
Web服务器的绑定方式发生了根本变化：
<!-- Boot 3.x：隐式绑定 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><!-- 自动包含Tomcat --></dependency><!-- Boot 4.0：必须显式声明 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><!-- 不再自动包含任何服务器！ --></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web-server-tomcat</artifactId></dependency><!-- 或选择 Jetty --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web-server-jetty</artifactId></dependency>如果你当前使用Undertow，迁移步骤：
- 排除
spring-boot-starter-undertow依赖 - 添加
spring-boot-starter-web-server-tomcat（推荐）或Jetty - 检查Undertow特有配置（如
server.undertow.*）并替换为对应容器的配置 - 重新测试WebSocket/SSE等长连接场景
2.2 声明式HTTP Client——一等公民化
4.0将声明式HTTP Client提升为框架级能力，类似Spring Cloud OpenFeign但无需额外依赖：
// 定义HTTP服务接口@HttpExchangepublicinterfaceBillingClient{@GetExchange("/api/bills/{id}")BillDTOgetBill(@PathVariableLongid);@PostExchange("/api/bills")BillDTOcreateBill(@RequestBodyCreateBillRequestrequest);}# 配置base-url（无需在注解中硬编码） spring.http.serviceclient.billing.base-url=https://billing.example.com// 启用服务客户端扫描@SpringBootApplication@ImportHttpServices(basePackages="com.example.clients")publicclassApplication{publicstaticvoidmain(String[]args){SpringApplication.run(Application.class,args);}}对团队的影响：微服务间的HTTP调用有了统一的声明方式，配合Spring Cloud的负载均衡和服务发现，可以大幅简化服务间通信代码。
三、API版本治理：框架内建
在大型微服务架构中，API版本管理一直是个头疼的问题。Spring Boot 4.0将其提升为框架级能力：
# 全局默认版本 spring.mvc.apiversion.default=1.0.0 # 使用Header传递版本号 spring.mvc.apiversion.use.header=X-Version@RestController@RequestMapping("/users")publicclassUserController{@GetMapping@ApiVersion("1.0.0")publicList<UserDTO>listV1(){// 返回V1格式的用户数据}@GetMapping@ApiVersion("2.0.0")publicList<UserDTOV2>listV2(){// 返回V2格式的用户数据，包含扩展字段}}前端在Axios拦截器中统一添加版本Header即可：
axios.interceptors.request.use(config=>{config.headers['X-Version']='1.0';returnconfig;});四、可观测性增强：OpenTelemetry成"标配"
4.0新增了spring-boot-starter-opentelemetry，将分布式追踪标准化接入能力内置到框架中。
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-opentelemetry</artifactId></dependency>这意味着：
- 不再需要手动引入各种OpenTelemetry依赖
- 框架自动配置Exporter、采样策略、Resource属性
- 与Spring Boot Actuator深度集成，端到端可观测
五、升级指南：推荐的五步法
不要直接从Boot 2.x跳到4.0——跨越太大，风险不可控。推荐路径：
Boot 2.x → Boot 3.5.x（中间过渡）→ Boot 4.0五步升级法：
- 先升到Boot 3.5.x：确保所有依赖在3.5.x上正常运行
- 清理所有deprecated API：避免升级后集中爆炸
- 补齐测试与观测基线：没有测试和指标数据，无法判断升级收益
- 重点回归验证：
- 容器/Servlet兼容性（Undertow → Tomcat/Jetty）
- JSON序列化行为（Jackson 3.x的日期格式、字段命名策略）
- JPA/Hibernate配置与方言
- Actuator端点与安全策略
- 灰度发布+准备回滚预案：按"升级项目"推进，而非简单"改版本号"
六、对不同角色的行动建议
研发工程师：
- 立即在测试环境中创建Boot 4.0分支，跑一遍集成测试
- 重点关注Jackson 3.x对JSON序列化的影响
- 如果使用Undertow，优先制定迁移计划
架构师/技术经理：
- 评估声明式HTTP Client对现有服务间通信方案的替代价值
- 规划API版本治理的统一策略
- 评估OpenTelemetry内置能力对现有可观测性架构的影响
前端开发者：
- Jackson 3.x升级可能导致后端返回的JSON结构变化（日期格式、字段命名等）
- 在HTTP拦截器层做好适配
- WebSocket/SSE实现方式可能因容器更换而受影响
个人观点
Spring Boot 4.0的本质是一次"清债"行动——将积累多年的技术债务（Servlet标准、容器绑定方式、API版本管理、可观测性接入）统一清算。Undertow的移除虽然激进，但也反映了社区对"收敛选择、做深做透"的决心。对于企业级项目，我的建议是：不要急，但一定要开始准备——4.0的代际变化意味着生态迁移是趋势，越早启动评估，升级时的成本越低。
