Spring Boot 4.0.2 做了什么？一句话版本概览
先给一个高度概括：
Spring Boot 4.0.2 是一个“专注修复、不搞花活”的稳定性版本。
它主要覆盖三大方向：
- 20+ Bug 修复：Kafka、WebFlux、Actuator、测试框架等核心模块均有涉及。
- 40+ 核心依赖升级：Spring Framework、Hibernate、Jackson、Reactor 全面跟进。
- 文档与元数据修正：清理错误说明、过期链接与配置误导。
但真正让这个版本变得“必须升级”的原因，只有一个——Kafka 事务自动配置终于回来了。
重磅修复：Kafka 事务自动配置失效问题彻底解决
问题有多严重？
对应的官方 Issue #48880，标题本身就非常直白：No TransactionAutoConfiguration with spring-boot-starter-kafka。
在 Spring Boot 4.0.0 或 4.0.1 中，只要你引入了 Kafka Starter 依赖，TransactionAutoConfiguration 这个关键的自动配置类就不会被加载。
这直接导致什么后果呢？
- 所有用
@Transactional标注的 Kafka 相关操作，事务注解完全不起作用。 KafkaTemplate的事务能力被静默禁用，而你很可能浑然不觉。- 最危险的是，消息发送与数据库操作之间可能出现不可恢复的数据不一致。
换句话说，如果你的生产环境恰好依赖 Kafka 来实现 Exactly-Once 语义或事务消息，这已经不是“潜在风险”，而是一颗随时可能引爆的定时冲击波。
根因解析：不是你写错，是框架加载顺序出问题了
问题根源不在于你的业务代码写得不对。这其实是 Spring Boot 4.0 在重构其自动配置体系时，无意中引入的一个副作用：
- Kafka Starter 的自动配置元数据，未能正确声明其对事务自动配置的依赖关系。
- 这个微小的缺失，直接导致
KafkaTransactionManager无法在应用上下文中被正确初始化和使用。
4.0.2 的修复方式
针对这个问题，Spring Boot 团队在 4.0.2 版本中做了三件关键事：
- 重新梳理并修正了 Kafka 自动配置的依赖链。
- 明确声明了事务自动配置的加载前置条件。
- 最终确保
KafkaTransactionManager在需要时一定可用。
社区对此的态度已经非常明确：只要你的应用在使用 Kafka 事务，那么从 4.0.0/4.0.1 升级到 4.0.2，就不是“建议”，而是“必须”。
除了 Kafka，这些修复同样值得注意
Bean 条件评估性能优化（#48840）
在高并发或大型微服务项目中，Spring Boot 在启动阶段会反复查询 BeanFactory，进行大量重复的条件判断，造成不必要的性能开销。
4.0.2 的优化策略非常直接：对条件评估的结果引入缓存机制，避免重复扫描。根据最新评估，这一改动能为启动性能带来约 10%～15% 的提升，对于需要快速扩缩容的云原生场景，这个增益相当可观。
Native Image 场景稳定性修复（#48812）
在 Ja va 25 + GraalVM 原生镜像环境中，之前存在一个棘手问题：Actuator 的 /info 端点会因为对 VirtualThreadSchedulerMXBean 的支持问题，直接导致整个应用启动失败。这对于追求极致启动速度和资源利用率的 Serverless 或云原生部署来说，影响非常大。
4.0.2 修复后，Actuator 在 Native Image 下的表现重归稳定，Spring Boot 的云原生支持能力也由此向前迈进了一步。
测试行为修正：端口终于符合直觉了（#48653）
之前存在一个反直觉的行为：当你使用 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT) 注解时，这个随机端口配置并不会应用到管理服务器（Actuator）上。结果就是，集成测试中主应用跑在一个随机端口，而 Actuator 却跑在另一个你没预料到的端口，给调试带来不少麻烦。
4.0.2 修复后，测试行为终于和开发者的直觉一致了，可以省下不少到处找端口的时间。
安全依赖去强耦合（#48685）
spring-boot-cloudfoundry 模块之前存在一个设计问题：它强制依赖了 spring-boot-security，即便你的应用根本不需要任何安全功能。这种强耦合显然不符合现代架构“按需引入”的理念。
4.0.2 版本对此进行了调整，将安全依赖改为可选。这意味着，你终于可以真正做到“用什么，引什么”，让依赖关系更加清晰、纯净。
核心依赖升级一览（重点版）
本次版本共升级了超过 40 项核心依赖，其中以下几项尤其值得关注：
- Spring Framework 7.0.3：修复了 SpEL 表达式中潜在的内存泄漏问题。
- Hibernate 7.2.1.Final：带来了二级缓存（L2 Cache）的性能优化。
- Jackson 2.20.2：全面增强了对 Ja va 25 新特性的支持。
- Micrometer 1.16.2：修复了 Prometheus 指标导出时可能遇到的线程安全问题。
- Reactor 2025.0.2：增强了背压处理能力，响应式编程更稳。
完整升级列表建议查阅官方 Release Notes。
唯一需要留意的破坏性变更
虽然影响面很小，但仍有必要提一下。
Jetty 依赖精简
在 spring-boot-starter-jetty 中，官方移除了 jetty-ee11-servlets 这个传递性依赖。如果你的项目代码直接使用了该模块中的特定类，升级后需要手动补充以下依赖：
org.eclipse.jetty.ee11
jetty-ee11-servlets
升级方式（推荐）
对于 Ma ven 项目，最直接的升级方式是更新父工程或依赖管理中的版本号：
org.springframework.boot
spring-boot-starter-parent
4.0.2
总结：这是一个“低调但致命重要”的版本
纵观全局，Spring Boot 4.0.2 表面上只是一个常规的 Patch 更新，但其修复的问题深度和广度，足以直接影响生产系统的数据安全性与运行稳定性。
- Kafka 事务失效？已修复。
- 启动性能有瓶颈？有感提升。
- 云原生/Native Image 支持不稳？现在更稳。
- 测试与依赖管理反直觉？更符合预期。
更值得期待的是后续发展。Spring Boot 4.1 版本已经进入预览阶段，根据官方文档透露的信息，接下来将开始探索对 Project Leyden（Ja va 静态镜像）的支持。这意味着，追求极致效率和资源利用率的道路将越走越宽。
所以，如果你正在为2026年的技术栈布局，那么现在将 Spring Boot 升级到 4.0.2，无疑是一个稳健而及时的选择。结论很清晰：能升就升，尤其是 Kafka 用户，建议立即行动。
