Spring Boot 4.0 于 2025年11月 正式发布，它基于 Spring Framework 7.0 构建，标志着 Java 应用开发正式迈入“后Loom时代”。其核心目标是全面拥抱 Java 重大新特性（如虚拟线程）并重构云原生支持。
核心基线升级
| 特性维度 | Spring Boot 3.x | Spring Boot 4.x | 说明 |
|---|---|---|---|
| Spring Framework | 6.x | 7.x | 核心容器重构，全面支持Project Loom |
| Java 基线 | Java 17 | Java 17 (推荐 Java 25) | 强烈建议使用 Java 21+ 以通过虚拟线程提升并发性能 |
| Jakarta EE | EE 10 | Jakarta EE 11 | 升级到 Servlet 6.1, JPA 3.2 等规范 |
| Kotlin | 1.9+ | 2.2+ | 利用 Kotlin 2.0 K2 编译器的性能优势 |
| GraalVM | 实验性/逐步成熟 | Native Image 25+ | AOT（Ahead-of-Time）编译成为一等公民，构建速度大幅提升 |
显著架构与功能变化详解
1. 虚拟线程的深度集成 (Virtual Threads)
核心变化
Spring Boot 4.x 将虚拟线程从“可选特性”提升为“默认并发模型”。这彻底改变了 Java Web 应用处理并发的方式。
扩展说明
在 3.x 时代，通过 Tomcat 线程池处理请求，线程数通常限制在 200 左右。一旦遇到慢查询，线程池就会耗尽，导致服务卡死。
在 4.x 时代，默认启用虚拟线程。每个 HTTP 请求分配一个极轻量级的虚拟线程。即使有 10000 个请求同时等待数据库返回，JVM 也能轻松应对，因为虚拟线程在等待 I/O 时几乎不消耗 CPU 资源。
带来的价值
● 高吞吐量：无需复杂的 Reactive 编程（WebFlux），用最简单的同步代码（Servlet）就能实现媲美 Go 语言的高并发性能。
● 简化配置：再也不用纠结 server.tomcat.threads.max 该设置多少了。
2. 声明式 HTTP 客户端 (Declarative HTTP Clients)
核心变化
Spring Boot 4.x 原生内置了声明式 HTTP 客户端支持，完全取代了 OpenFeign。
扩展说明
以前为了调用远程服务，我们通常会引入 spring-cloud-starter-openfeign。现在，Spring Framework 核心包里直接送了这个功能，名字叫 Interface Clients。
它基于现代化的 RestClient (同步) 或 WebClient (异步)，性能更好，且不需要引入额外的 Spring Cloud 依赖，大大降低了微服务间调用的复杂度和包体积。
代码对比
// Spring Boot 4.x 原生支持，无需 @EnableFeignClients
@HttpExchange("/products")
public interface ProductClient {
@GetExchange("/{id}")
Product getProduct(@PathVariable Long id);
}
3. 模块化重构 (Modularization)
核心变化
对庞大的 Starter 依赖进行了物理拆分，支持 Java 9+ 的 JPMS 模块化系统。
扩展说明
随着 Spring Boot 功能越来越全，引入一个 spring-boot-starter-web 可能会带入几十兆的依赖。
4.x 版本将核心库拆分得更细。比如，如果你只需要 Spring MVC 的核心注解，而不需要 Tomcat（因为你想用 Undertow），你可以利用模块化特性更精准地引入依赖。
这尤其利于 GraalVM Native Image 的构建，因为依赖越少，分析越快，构建出的二进制文件越小，启动速度越快。
4. 原生 API 版本控制 (Native API Versioning)
核心变化
Spring MVC 终于内置了对 API 版本管理的支持。
扩展说明
在开发 REST API 时，版本管理（v1, v2）是刚需。以前我们可能通过 URL 硬编码 (/v1/...) 或者自己写拦截器处理。
现在，你可以直接在 Controller 上配置版本策略。Spring 会自动根据配置（URL路径、请求头、参数等）将请求路由到对应的方法，非常利于 API 的长期维护和演进。
5. 可观测性 2.0 (Observability)
核心变化
Spring Cloud Sleuth 正式退役，OpenTelemetry 成为唯一标准。
扩展说明
可观测性包括三大支柱：Logs（日志）、Metrics（指标）、Traces（链路追踪）。
● 3.x 时代：Sleuth 负责追踪，Micrometer 负责指标，两者相对独立。
● 4.x 时代：Micrometer Tracing 全面接管，底层实现向 OpenTelemetry（CNCF 行业标准）对齐。这意味着 Spring Boot 产生的所有监控数据，可以无缝直连 Grafana、Prometheus 或 Jaeger，中间不再需要复杂的转换适配。
6. Null Safety 与 JSpecify
核心变化
Spring 全面采纳 JSpecify 标准注解来处理空安全，统一了 Java 生态的“方言”。
扩展说明
用个生动的比喻：
● 过去（方言混战）：Spring 用自己的 @Nullable，安卓用安卓的，FindBugs 用 FindBugs 的。IDE（如 IntelliJ IDEA）和 编译器（如 Kotlin）经常不知道该听谁的，导致空指针检查时灵时不灵，或者误报。
● 现在（统一普通话）：JSpecify 是 Google、JetBrains、Spring 等联合制定的行业标准。Spring Boot 4.x 就像宣布“只讲普通话”，使用了标准的 @org.jspecify.annotations.Nullable。
● 好处：
a. IDEA 不再犯晕：任何支持标准的工具都能精准识别变量是否可为空。
b. Kotlin 完美互操：Kotlin 编译器能 100% 确定 Java 变量的可空性，彻底告别恼人的“平台类型（Platform Types）”空指针隐患。
迁移建议
如果您正在规划从 3.x 升级到 4.x，建议采取以下步骤：
- 升级到 3.5.x：利用官方提供的 OpenRewrite 工具修复所有被标记为 Deprecated 的代码。
- JDK 升级：确保生产环境运行时至少支持 Java 21 LTS，最好是 Java 25。
- 移除 Feign：开始尝试将 Feign 客户端迁移到 Spring Interface Client。
- Native 评估：对于 Serverless 或启动速度敏感的微服务，开始评估 GraalVM Native Image 的可行性。
评论区