Spring Boot 4.0 正式发布，王炸！！
大家好，我是R哥。
距离《Spring Boot 3.0 正式发布，王炸！！》已经 3 年了，Java 的世界经过了一次大变天，现在 Spring Boot 4.0 都来了，从 3.5 直接干到了 4.0。
Spring Boot 4.0.0 正式发布了：
最新的支持版本如下：
从路线图可以看到每个版本的终止时间，每个版本的生命周期只有一年。
Spring Boot 3.3.x 及以下开源版本全部停止维护了，Spring Boot 3.4.x 马上也要停止维护了，开源支持的版本马上要进入 3.5+ 版本的时代了，商业支持的 3.x 最高版本版本 3.2.x、2.x 为 2.7.x。
Spring Boot 3.0+ 很快要成为过去式了，Spring Boot 马上要进入了全新的 4.0+ 时代了，2.6.x 以下的版本彻底退出历史舞台，技术变革太快了，赶紧学起来。。
Spring Boot 4.0.0 新特性
Spring Boot 4.0 无疑又是一次超神的版本，带来了诸多重大升级，一起来看看。
1、最低环境要求
和 Spring Boot 3.0 保持一致，Spring Boot 4.0.0 最低要求也还是 Java 17，但最高支持的版本为 Java 25，Spring 也来到了全新的 Spring 7+。
Java 的目前最新版本为 Java 25：
对 Java 开发环境的要求对比表：
| Spring Boot | JDK | Spring | Maven | Gradle |
|---|---|---|---|---|
| 4.0.0 | 17 ~ 25 | 7.0.1+ | 3.6.3+ | 8.14+,9.x |
| 3.5.0 | 17 ~ 24 | 6.2.7+ | 3.6.3+ | 7.6.4+,8.4+ |
| 3.4.0 | 16 ~ 23 | 6.2.0+ | 3.6.3+ | 7.6.4+,8.4+ |
| 3.3.0 | 17 ~ 22 | 6.1.8+ | 3.6.3+ | 7.5+,8.x |
| 3.2.0 | 17 ~ 21 | 6.1.1+ | 3.6.3+ | 7.5+,8.x |
| 3.1.0 | 17 ~ 20 | 6.0.9+ | 3.6.3+ | 7.5+,8.x |
| 3.0.0 | 17 ~ 19 | 6.0.2+ | 3.5+ | 7.5+ |
| 2.7.18 | 8 ~ 21 | 5.3.31+ | 3.5+ | 6.8.x, 6.9.x, 7.x, 8.x |
Spring Boot 4.0 嵌入式容器仅支持 Servlet 6.1+，Tomcat 11.0.x+ 和 Jetty 12.1.x，Undertow 已经移除支持了，我下面会说。
支持 Java 8 的最后一个 Spring Boot 2.x 系列版本早已已经退伍啦，Java 17 的新时代彻底到来。
如果你还停留在 Java 8 就 OUT 了，过去 2、3 年，Java 8 的采用率腰斩，Java 17+ 暴涨，新项目基本都是 Java 17+, Java 21+ 了。
R哥制作的《Java 新特性实战课》都可以报名学起来，好课不贵，199 元永久学习，如出新版本新内容都能免费更新。
2、Spring Boot 模块化
Spring Boot 代码库彻底模块化了，现在打包更小、更专注，用起来更清爽！
要知道，Spring Boot 1.0 于 2014 年发布时，只有一个spring-boot-autoconfigurejar 文件，大小仅为 182 KB。
当然，最初的版本支持的功能并不多，但经过多年发展，Spring Boot 已经变得越来越臃肿了。到了 Spring Boot 3.5，这一个spring-boot-autoconfigurejar 包竟然达到了 2 MB！
因为 Spring 的最大优势之一在于它支持的技术种类繁多，每支持一项新技术，自动配置的 jar 包自然就会增大。
Spring Boot 4 对自动配置的打包、交付和使用方式进行了根本性的变革，spring-boot-autoconfigure 不再使用单一的、庞大的 JAR 包，而是将功能拆分成更小、更专注的模块。
这样做的好处也相当显著：
- 可维护性和架构清晰度：通过更小的模块和强制执行的边界，团队和贡献者可以更清晰地理解每个领域。
- 减少组件体积和占用空间：你的应用现在只会拉取真正用到的模块，而不是像以前那样，一股脑儿地塞给你一个包含各种你可能根本用不上的功能的大型 autoconfigure jar 包。这样一来，classpath 的开销、启动扫描的成本以及磁盘空间都能得到有效降低。
- 更强的信号和避免意外的自动配置：由于模块是限定范围的，所以 Spring Boot 能更清晰地判断你引入依赖的原因，不需要调用
SpringApplication.setWebApplicationType(WebApplicationType.NONE)了。 - 新用例解锁：模块化已经开启了很多新的用例，比如说，现在你可以独立使用 Micrometer metrics，而无需依赖完整的 Actuator 包了，这在 Spring Boot 3.x 中是很难做到的。
比如，在 Spring Boot 3.x 时代是一个大管家，启动器都会自动包含其相关的模块，比如当 XX 包存在时，XX 就会自动配置。但在 Spring Boot 4 中，都已经模块化了，需要自己引入 XX starter 以确保安装了 spring-boot-xx 模块才会生效。
3、API 版本控制
Spring 实现 API 版本控制一直是个痛点，官方并没有提供内置支持，过去需要自己绕道实现，比如通过 HTTP 请求参数、自定义 HTTP Header 的方式来实现，非常复杂。
Spring 7.0 官方提供的 API 版本控制功能来了，Spring Boot 4.0 现在也对 API 版本控制提供了自动配置，同时支持 Spring MVC 和 Spring WebFlux。
现在 API 版本控制可以通过 spring.mvc.apiversion.* 或 spring.webflux.apiversion.* 属性进行配置。一旦 API 版本控制启用，你就可以开始映射带版本的请求了。
注解 @RequestMapping version 属性支持以下功能：
- 默认没有值：匹配任何版本；
- 固定版本（比如 "1.2"）：只匹配指定的这个版本；
- 基线版本（比如 "1.2+"）：匹配指定的版本及更高版本。
如果多个 Controller 方法的版本都小于或等于请求版本，那么会选择版本最高且最接近请求版本的那个，其他的就直接被干掉了。
我们来看看下面这些映射的例子：
@RestController
@RequestMapping("/account/{id}")
public class AccountController {
// 1、匹配任意版本
@GetMapping
public Account getAccount() {
}
// 2、匹配版本 1.1
@GetMapping(version = "1.1")
public Account getAccount1_1() {
}
// 3、匹配版本 1.2+
@GetMapping(version = "1.2+")
public Account getAccount1_2() {
}
// 4、匹配版本 1.5
@GetMapping(version = "1.5")
public Account getAccount1_5() {
}
}
我们来分析以下几种不同版本的请求：
如果此时发送一个版本为 "1.3" 的请求？
只有 3、匹配版本 1.2+ 才匹配，因为它是最接近 1.3 的最高版本，1.5 的版本高于 1.3，所以不匹配。
如果此时发送一个版本为 "1.5" 的请求？
当然只有 4、匹配版本 1.5 精准匹配。
如果此时发送一个版本为 "1.6" 的请求？
此时，没有一个版本可以匹配，这种情况下， NotAcceptableApiVersionException 会返回一个 400 错误。
这样做是不是比传统的实现方式要简单、优雅多了？
如果想要更高级的控制，可以定义
ApiVersionResolver、ApiVersionParser和ApiVersionDeprecationHandler类型的 Bean。
4、HTTP Service Clients
Spring Boot 现在原生支持 HTTP 服务客户端的自动配置和配置属性了，这玩意儿能让你直接在普通的 Java 接口上加个注解，Spring 就能自动给你生成实现类，省心又省力！
如下面示例：
@HttpExchange(url = "https://echo.zuplo.io")
public interface EchoService {
@PostExchange
Map<?, ?> echo(@RequestBody Map<String, String> message);
}
使用 @HttpExchange 注解定义一个接口，使用 @PostExchange 来修饰方法，就能用来调用 Echo 服务，很神奇吧？
5、移除 Undertow
Spring Boot 4.0 已经移除了对 Undertow 嵌入式 Servlet 容器的支持：
Spring Boot 4.0+ 之后，嵌入式 Servlet 容器只支持 Tomcat 和 Jetty 了。
为什么 Spring Boot 4.0 要移除 Undertow？
因为 Spring Boot 4.0+ 已经升级到了 Servlet 6.1+ 规范，但 Undertow 却不支持 Servlet 6.1+，所以 Spring Boot 只能忍痛割爱，移除了对 Undertow 的支持。
更多解读请参考这篇文章：
6、其他
Spring Boot 4.0 还完成了以下几件大事：
- 可观测性增强，比如新增 OpenTelemetry starter，Redis 观测从延迟记录器切到 MicrometerTracing，SSL 和 MongoDB 的健康检查逻辑也做了调整和扩展。
- 数据与基础设施方面增加 Redis 静态主从、MongoDB BigDecimal 存储配置、JmsClient 支持，以及用于集成测试的 RestTestClient。
- 平台层面，大量 Spring 家族组件和 Tomcat、Hibernate、Kotlin、OpenTelemetry 等第三方库统一升级到新主版本。
- 兼容性上，通过属性重命名、收紧自动配置的对外 API 来规范边界，同时 Jackson 2 的支持整体被标记为弃用，实际推荐迁移到 Jackson 3，这是升级时必须特别注意的一点。
- ……
本次升级的细节实在太多了，真的总结不过来，总之升级得注意了。
总结
Spring Boot 4.0 的发布，标志着 Java 应用开发迈入了一个全新的时代。
从模块化的到来，再到 API 版本控制和 HTTP 客户端的内置支持，这一代 Spring Boot 不仅在技术架构上进行了深度革新，也大大提升了开发体验与可维护性。
相比于 3.x 版本，Spring Boot 4.0 最大的亮点在于 “轻量化”和 “明确边界”，模块拆分让项目更精简、加载更快，也避免了不必要的自动配置。而 API 版本控制和 HTTP 客户端的原生支持，则弥补了长期以来开发者的痛点，使构建 RESTful 服务更加优雅和高效。
当然，随之而来的挑战也不少，Undertow 的移除、Jackson 3 的替代、自动配置规则的收紧，都要求开发者对项目依赖更加清晰可控，老旧项目的升级压力不容忽视。
总的来说，Spring Boot 4.0 是一次颠覆式的升级，值得所有 Java 开发者认真学习与拥抱。
新的开发范式已经到来，你准备好了吗？
话说你们现在用的什么版本呢？
特别是对很多还停留在 Spring Boot 2.x 或 Java 8 的朋友来说，是时候认真考虑升级了，因为这些新功能不只是新，更意味着性能提升、安全增强、开发便捷、生态进化，而这正是我们做后端开发最核心关注的方向。
Spring Boot 实战代码已上传 Github：
如果你还没用过 Spring Boot，这里推荐下我的《Spring Boot 核心技术课》，17 个模块，几乎涉及所有核心技术，包括底层实现原理及代码实战，知识点非常齐全，助你快速打通 Spring Boot 的各个环节。
有需要的直接扫码订阅：
早订阅，早学习，早受益。
好了，今天的分享就到这里了，后续R哥也会继续关注并分享更多的 Spring Boot 资讯和干货，关注公众号Java技术栈第一时间推送。
版权声明： 本文系公众号 "Java技术栈" 原创，转载、引用本文内容请注明出处，抄袭、洗稿一律投诉侵权，后果自负，并保留追究其法律责任的权利。
浙公网安备 33010602011771号