引言

Broadcom 于 2025 年 11 月发布了 Spring Framework 7.0 和 Spring Boot 4.0（官方公告见此处和此处）。新版本框架引入了原生 REST API 版本控制、用于实现整个 Spring 产品栈标准化空值安全的 JSpecify 注解，以及内置的弹性能力（包括重试机制和并发限流）。Spring Boot 4.0 采用 Jackson 3 来处理 JSON，并将原有的单体自动配置 JAR 拆分为多个独立模块。Spring Framework 7.0 仍以 JDK 17 作为基线版本，同时支持 JDK 25，并将 Jakarta EE 11 和 Kotlin 2.2 升级为新的基线版本。

Spring Boot 4 发布后，多个 Spring 相关项目也相继推出了主要版本，包括 Spring Cloud、Spring Modulith 和 Spring Shell。Spring Boot 4.1 预计将于 2026 年 5 月发布。

InfoQ 近日与 Broadcom Spring 团队核心成员展开交流，探讨了 Spring Framework 7 与 Spring Boot 4 带来的重大架构升级与功能改进。本次对话围绕其战略转变展开，包括将重试、并发限流等能力直接集成到框架内核来实现核心弹性，以及模块化自动配置所带来的性能提升。

专家组还探讨了对 HTTP API 版本控制的原生支持实现方案，以及 AI 编码工具在现代开发者工作流程中带来的变革性作用。最后，团队给出了从 Spring Boot 3 升级至 4 的指南，重点介绍了可用于简化企业应用迁移的专用工具、兼容模块及社区资源。

专家组成员

• Phil Webb，Spring Boot 联合创始人兼负责人

• Sam Brannen，Spring Framework 核心提交者和 JUnit 5 维护者

• Rossen Stoyanchev，Spring Framework 提交者：Spring MVC、WebFlux

• Mark Pollack，Spring AI 项目创始人

• Martin Lippert，Spring Tools 项目负责人

• Michael Minella，开源 Spring 研发团队总监，前 Spring Batch 负责人

InfoQ：Spring Boot 4 的自动配置模块化在实际应用中会带来怎样的性能影响？你认为这又将如何影响第三方 Starter 的开发？

Phil Webb：性能并非本次模块化改造的核心目标，但我相信在启动耗时上会有一定优化。许多自动配置类仅在类路径中检测到特定类时才会触发，而在早期版本的 Spring Boot 中，应用每次启动都需要检查大量类。模块化后，需要检查的类数量会大幅减少。

另一项小幅性能提升是最终构建的可执行 JAR 包的体积上。只引入所需模块可以让 JAR 体积更小，需要读取的数据量也随之减少。

InfoQ：为什么将 Spring Retry 集成到 Spring Framework 中，而不是保持其模块化独立？

Sam Brannen：核心弹性能力是 Spring Framework 7 的一大核心方向，为此我们新增了重试支持以及基于注解的并发限流功能。

从历史来看，Spring 社区一直依靠 Spring Retry 项目实现各种形式的重试能力。而在 Spring 7 中，我们决定将核心重试支持纳入 Spring 产品体系的最底层，即 Spring Framework 自身。尽管这项能力的设计思路源自 Spring Retry 项目，但我们已对其进行全面重构，在 spring-core 和 spring-context 模块中实现了一套精简的核心重试功能。这让所有 Spring 开发者无需额外引入依赖，即可直接使用 RetryTemplate 和 @Retryable。简单来说，核心重试能力将始终可用，Spring Framework 自身也能基于这些重试能力进行构建，例如在 RestClient 中。

在功能方面，RetryTemplate 允许开发者在代码中直接使用程序化重试，可完全自主控制重试策略与退避策略。而 @Retryable 则提供了声明式方式，开发者只需在类或方法上添加该注解并通过注解属性指定重试与退避配置即可。@Retryable 天然支持命令式编程模型；与 Spring Retry 项目不同的是，Spring Framework 中的 @Retryable 还可用于返回响应式类型的方法。Spring 会借助 Project Reactor 的 Retry 规范来装饰响应式流。对于非响应式返回类型，Spring 则会配置 RetryPolicy 并委托给 RetryTemplate 处理。

最后，@ConcurrencyLimit 允许开发者为指定方法调用配置并发限制。该机制能有效保护目标资源不被过多线程同时访问，效果类似于线程池或连接池的大小限制，超出限制时会阻止访问。这种限制在使用虚拟线程（Virtual Threads）时尤为实用，因为虚拟线程通常不受线程池容量的约束。

InfoQ：Spring Framework 7 基于 HTTP 头实现 API 版本控制，你们计划如何与 JavaScript、Python、.NET 等社区协作，让这些版本更易于它们接入使用？

Rossen Stoyanchev：Spring Framework 7 服务器端应用可以从多种 API 版本策略中做出选择，包括路径、请求头、查询参数或媒体类型参数，具体方案需要综合多方面因素来确定。

一个关键因素是预期变更的深度。例如，基于路径的版本控制可以适配底层领域模型中更深度的结构性变更；而基于请求头和查询参数的版本控制则适用于更轻量级的变更，支持按需对控制器映射进行渐进式版本管理。

另一个因素是不同 REST API 规范的存在。例如，如果需要或选择遵循微软 REST API 指南，可选用路径版本（如 v1.0）或 api-version 查询参数。而如果遵循 Zalando RESTful API 指南，则使用 version 媒体类型参数。

鉴于可选方案与行业实践种类繁多，Spring Boot 不会提供开箱即用的默认配置。应用程序必须显式地启用 API 版本控制，并自行选定版本策略，以及请求头/查询参数名称、版本格式（如语义化版本或日期版本）等细节。最终决定权完全交由开发人员掌握。

从着手设计 API 版本控制功能之初我们就明确，这是一个复杂的领域，存在诸多不同观点，并没有放之四海而皆准的方案。因此我们的目标并非强制或引导开发者选用某一套特定方案，而是提供基础构建模块，赋予开发者自主权并支持他们做出的任何选择。

客户端需要遵循服务器端的约定。例如，如果你编写客户端调用 GitHub REST API，就需要使用 X-GitHub-Api-Version 请求头。从这个角度而言，版本策略的具体实现与技术栈关系不大，更多取决于应用自身的 REST API 设计选择。

Spring 的 RestClient 和 WebClient 构建器支持一次性配置 API 版本控制，这样在发起请求时业务代码无需处理具体的 HTTP 请求细节。同样，HTTP 接口客户端的 HttpExchange 注解现已支持版本属性，并与 HTTP 请求细节解耦，相关配置可统一设置，无需修改请求调用代码。预计 JavaScript、Python、.NET 及其他客户端库也会提供类似的功能与可配置能力。

InfoQ：你在 Spring 项目中使用 Claude Code、GitHub Copilot 或 Google Gemini 这类 AI 编码工具的体验如何？你认为这些新工具会给 Spring 开发者的工作带来怎样的改变？

Mark Pollack：这些工具带来的使用体验极具变革意义。我认为各类开发者都不会再沿用过去二十年的编程方式了。对于经验丰富、具备优秀设计能力的开发者而言，与现代 AI 编码工具协作堪称颠覆性突破。我们还需要时间观察哪些开发者能真正高效运用这些工具。因此，我对这类工具在编码领域的变革作用十分看好。也有人持不同意见，尤其是那些喜欢问 AI 类似“ strawberry 里有多少个字母 r ”、并热衷于揪出这类简单问题错误的人，但简而言之，这就是我个人的真实感受。

InfoQ：包含详细规则、规范与最佳实践的文档能够引导 AI 编码工具生成更高质量的代码。对 Claude Code 而言，这类文档可以作为技能配置或子智能体使用。你们是否计划发布此类文档？例如可以是针对特定项目的，如 Spring Web MVC 或 Spring Data，也可以是通用型的，涵盖安全或性能等横向共性问题。

Martin Lippert：这确实是个很有意思的话题。我们正在积极研究可以直接落地的方案，以及通过合作能实现的内容，但目前一切还处在探索阶段。即将发布的 Spring Tools 5 将成为首批适配 AI 编码环境的 Spring 工具，例如它会提供相关能力，向工作区项目周边的编码助手提供更深入的 Spring 相关洞察。我们下一步的具体规划尚未最终确定。

InfoQ：Spring Boot 4 给不少开发者带来了升级方面的挑战，其中包括 Jackson 3 包名变更与 JSpecify 空值注解适配。开发者可借助哪些工具或 AI 支持来完成 Spring Boot 3 应用的升级工作？

Phil Webb：我们很庆幸拥有一个活跃的开发者社区，社区成员试用了早期里程碑版本并给出了很好的反馈。这促使我们优化了部分决策，以便更好地帮助需要升级的开发者。例如，我们专门提供了一个 Jackson 2 兼容模块，因为我们了解到目前许多生态系统尚未迁移至 Jackson 3。

我们同时也在升级内部的应用程序，来亲身体验升级过程中的痛点。我们惊喜地发现，许多典型的 Spring Boot 应用程序无需花费太多精力即可完成升级。例如，不少包重命名仅涉及自动配置类，而这些类用户通常不会直接导入。我们还针对性地为重命名的配置属性提供了工具支持，让 IDE 和属性迁移工具包能够帮助开发者快速找到替代项。

计划升级的开发者可以先参考我们 Wiki 上的迁移指南。我们预计社区可能会像以往一样，针对常见迁移问题提供对应的 OpenRewrite 规则。购买了 Broadcom 技术支持的客户可以使用 Application Advisor 工具 进行升级。

当然，任何重大版本升级都无法做到完全顺畅无阻。我们也预计，对 Spring Boot 进行深度集成与扩展的用户相比普通应用开发者需要投入更多时间完成升级。

InfoQ：Spring Boot 2.7 在 Spring Boot 3 发布时仍有 12 个月的免费维护期，之后还提供了 37 个月的付费支持。Spring Boot 3.5 目前还有 7 个月免费维护期，将于 2026 年 6 月结束，随后将提供长达 72 个月的付费支持。你认为这会对企业采用 Spring Boot 4 产生怎样的影响？

Michael Minella：从我们与用户的交流来看，开源支持时长的几个月差异并不会影响他们的升级时机。社区在一年多前就已经知道这个主要版本即将发布，那些选择继续使用开源支持版本的用户在此期间也一直参与其中。为了让用户尽早参与进来，我们在这个版本周期中首次向 Maven Central 发布了里程碑版和候选版，这使得反馈数量显著增加，也让我们能够进一步优化这些版本。

不过对大多数用户而言，企业支持周期的大幅延长切实影响了他们管理应用集群的方式。无论是选择投入更多时间完成重大版本升级，还是利用延长支持为计划下线、不再投入维护的应用提供保障，这两种都是目前产品中切实可用的选择。

我们理解所有这些场景。尽管我们坚信，对用户而言保持版本最新是最优选择（我们也通过 Application Advisor 提供了相应工具），但我们同样构建了配套方案来覆盖所有的选项，因为并非每个应用程序都需要同等程度的维护投入。

结论

Spring Boot 4 引入了模块化自动配置，通过减少类路径检查来提升启动速度，并生成更小的 Jar 包。Spring Framework 7 通过 RetryTemplate 和 @Retryable 内置了重试支持，以及用于并发限流的 @ConcurrencyLimit，这个注解在使用虚拟线程时尤为实用。API 版本控制支持路径、请求头、查询参数和媒体类型等多种策略，Spring Boot 不会强制指定默认方案。Spring 团队认为 AI 编码工具具有变革性价值，并计划推出具备 AI 适配能力的 Spring Tools 5，而更全面的 AI 指导文档目前仍在研究阶段。

升级到 Spring Boot 4 后，大多数常规应用程序只需投入合理成本即可完成迁移。Jackson 2 兼容模块可简化向 Jackson 3 的过渡升级，IDE 工具也能协助处理配置属性的重命名问题。官方 Wiki 上的迁移指南是最佳起点，社区提供的 OpenRewrite 规则可自动化大部分迁移工作。购买了 Broadcom 商业支持的客户还可使用 Application Advisor 工具。

关于支持时间表，Spring 团队表示，Spring Boot 3.5 缩短的免费开源支持周期（在 Spring Boot 4 发布后仅剩余 7 个月）并未对大多数用户的升级时间安排造成明显影响。而大幅延长的企业支持周期（如今付费支持长达 72 个月）则为企业提供了更大灵活性，使其可以按自身节奏规划升级，或维护那些计划淘汰的应用程序。

【声明：本文由 InfoQ 翻译，未经许可禁止转载。】

查看英文原文：https://www.infoq.com/articles/spring-team-spring-7-boot-4/