Spring Boot on 吾爱主机

Spring Boot 3.5.16 发布后，团队现在该怎么做：升级、验证与 3.5 生命周期收尾指南

Mon, 29 Jun 2026 15:21:35 +0000

Spring 团队在 2026-06-25 发布了 Spring Boot 3.5.16。如果你还在 3.5.x 线上维护窗口内，这个版本值得关注，因为它不仅是一个常规补丁版，还带着一个更重要的信号：3.5.x 已经来到开源维护周期的最后阶段。

这篇文章不重复官方公告，而是从工程落地角度整理成一份中文操作指南：这次版本到底变了什么、哪些团队应该马上升、升完要验证什么、以及如果你准备继续停留在 3.5 分支，应该怎样安排后续计划。

一、先说结论：3.5.16 是什么性质的版本

根据 Spring 官方博客，Spring Boot 3.5.16 已于 2026-06-25 发布，本次发布包含 3 项依赖升级。同时，官方明确说明它是 3.5.x 代际的最后一个 OSS 发布版本，后续若需要更长周期支持，需要转向商业支持方案。

结合 Spring Boot GitHub Release 与生命周期数据，可以把这个版本理解成：

它是 3.5.x 的收官补丁版本；
它不是一个新特性大版本，而是维护型版本；
对仍在 3.5.x 的团队来说，它很适合作为该分支的最终稳定落点；
如果你们还没有升级到 4.0/4.1，那么现在至少应先把 3.5.x 升到 3.5.16，再规划后续迁移。

二、这次实际更新了什么

从 Spring Boot 3.5.16 的 GitHub Release 页面可以确认，本次补丁版包含 3 个依赖升级：

Spring AMQP 3.2.12
Spring Data BOM 2025.0.13
Spring Integration 6.5.10

这说明 3.5.16 的核心价值并不是引入新的框架行为，而是：

对 3.5 代际已纳入管理的依赖做最后一轮维护性更新；
尽量把生态内相关模块收敛到更稳定的补丁位；
给仍在 3.5 线上运行的项目提供一个更明确的“最终补丁基线”。

如果你的应用显式或隐式使用了以下能力，建议优先升级并回归：

RabbitMQ / Spring AMQP 消息处理；
Spring Data 相关持久层能力；
Spring Integration 驱动的集成流、适配器或消息编排。

三、为什么这个版本值得今天就处理

很多团队看到“只有 3 个依赖升级”时，容易觉得可以先放一放。但从维护节奏上看，这次比功能变化更重要的是支持窗口变化。

生命周期数据表明：

Spring Boot 3.5 首次发布时间为 2025-05-31；
3.5.x 的 OSS 支持截止日期为 2026-06-30；
商业支持可延长到 2032-06-30；
截至校验时，3.5 分支最新版本就是 3.5.16（2026-06-25）。

这意味着什么？

1）你还在 3.5.x，就应该把 3.5.16 当成收官版看待

后续即便应用继续稳定运行，也不能再默认期待有新的公开补丁不断跟进。对生产团队来说，落在最后一个 OSS 补丁版本上，比停留在更早的 3.5.x 小版本上更稳妥。

2）升级 3.5.16 和规划下一跳，是两件要并行做的事

正确做法不是“反正马上要升 4.x，就不升 3.5.16 了”，而是：

短期：先把生产基线更新到 3.5.16；
中期：评估是升到 4.0 还是直接跟进 4.1；
长期：决定是否需要商业支持兜底。

因为 3.5.16 是补丁升级，风险通常远低于跨代升级。先完成这一步，可以降低你在迁移前的运行风险。

四、哪些项目应该优先升级

下面几类项目，建议你优先安排升级窗口：

1）仍在长期维护的存量业务系统

如果系统没有立刻升级到 4.x 的资源，但还要持续运行几个月甚至更久，那么停在 3.5.16 是更合理的选择。

2）依赖 Spring Data / Spring Integration / AMQP 的集成型系统

这次补丁直接涉及这些依赖线，消息、数据访问、系统集成相关项目更应该完成回归验证。

3）准备做 3.5 → 4.x 升级演练的团队

先把 3.5 基线统一到 3.5.16，再做跨代升级，排障边界会更清晰。否则你很难分辨问题来自：

旧的 3.5.x 补丁差异；
还是 4.x 的行为变化。

五、怎么升级到 3.5.16

大多数项目只需要改版本号，然后走一次标准构建与回归。

Maven

如果你使用 spring-boot-starter-parent：

<parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>3.5.16</version>
 <relativePath/>
</parent>

如果你使用 Spring Boot BOM：

<dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-dependencies</artifactId>
 <version>3.5.16</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>
 </dependencies>
</dependencyManagement>

Gradle

如果你通过 Spring Boot Gradle Plugin 管理版本：

plugins {
 id("org.springframework.boot") version "3.5.16"
 id("io.spring.dependency-management") version "1.1.7"
 kotlin("jvm") version "2.2.0"
}

如果你的项目并不使用 Kotlin 或不需要显式声明这些插件版本，请按你们自己的构建脚本风格调整，核心是把 Spring Boot 版本对齐到 3.5.16。

六、升级后重点验证什么

虽然 3.5.16 本身是补丁版，但 3.5 这一代并不是完全没有行为约束变化。Spring Boot 3.5 Release Notes 中有几项很适合作为升级后的重点回归清单。

1）`heapdump` 端点默认访问策略变更

在 3.5 代际中，heapdump Actuator 端点默认变成了 access=NONE。如果你们过去只做了暴露配置，没有显式设置访问策略，那么升级后相关诊断链路可能与旧行为不同。

如果你确实需要启用它，应同时配置暴露与访问权限，例如：

management:
 endpoints:
 web:
 exposure:
 include: heapdump
 endpoint:
 heapdump:
 access: unrestricted

建议你在测试环境确认：

端点是否仍按预期可访问；
安全配置是否仍符合内网/零信任策略；
是否存在把高敏感诊断端点暴露到错误网络边界的风险。

2）布尔型配置值解析更严格

3.5 代际对 .enabled 这类布尔配置的可接受值收紧为更一致的 true / false。如果你的历史配置里混入了不规范值，升级后应检查是否产生行为变化。

建议排查：

application.yml / application.properties；
环境变量注入后的映射值；
Helm Chart / Kustomize / Ansible 模板里的布尔值渲染方式。

3）Profile 命名校验更严格，但 3.5.1 起已部分放宽

Spring Boot 3.5 代际增强了 Profile 命名校验；官方 Release Notes 同时说明：从 3.5.1 开始，这些限制已部分放宽，额外允许 .、+、@ 字符，也可以通过 spring.profiles.validate=false 关闭校验。

如果你们组织里有历史遗留 Profile 命名习惯，比如：

prod-cn
gray@hz
perf.test

建议在升级后跑一次完整启动验证，确认 Profile 解析与加载顺序没有偏差。

4）按名称注入 `taskExecutor` 的代码需要留意

Spring Boot 3.5 Release Notes 明确指出：自动配置的 TaskExecutor 不再同时提供 taskExecutor 和 applicationTaskExecutor 两个 Bean 名称，现在只提供 applicationTaskExecutor。

如果你们代码里存在按名称获取执行器的写法，例如：

@Qualifier("taskExecutor")
手动 getBean("taskExecutor")
XML 或脚本化配置里写死旧名称

那就要重点回归这部分逻辑。更稳妥的做法是改成依赖 applicationTaskExecutor，避免在未来版本继续背兼容包袱。

七、升级前后的实操检查单

为了让这次补丁升级更可控，可以按下面的顺序执行。

升级前

锁定当前生产版本与构建产物；
导出一份依赖树，确认是否显式覆盖了 Spring AMQP、Spring Data、Spring Integration 相关版本；
识别所有依赖 Actuator、TaskExecutor、Profile、布尔配置开关的模块；
准备至少一轮完整的自动化测试与一轮烟雾验证。

升级中

把 Spring Boot 版本提升到 3.5.16；
执行依赖刷新；
运行单元测试、集成测试、启动测试；
对消息链路、数据库访问、接口调用、定时任务做重点验证。

升级后

检查 /actuator/health、/actuator/info 以及你们自定义观测端点；
检查日志里是否出现 Bean 注入名称变化、配置绑定失败、Profile 校验失败；
观察消息积压、线程池使用率、慢 SQL、启动耗时；
将 3.5.16 标记为 3.5 分支最终基线，并启动 4.x 升级计划。

八、现在是继续留在 3.5，还是直接上 4.x？

截至核实时，Spring 官方项目页显示 Spring Boot 当前最新主线版本为 4.1.0。因此从路线选择看，团队通常有三种策略：

策略 A：先稳定到 3.5.16，再规划 4.1

适合：生产系统多、变更窗口谨慎、近期不适合跨代升级的团队。

优点：

风险最低；
便于先完成一次补丁级基线收敛；
给 4.x 迁移预留独立测试周期。

策略 B：在测试环境同时启动 3.5.16 与 4.1 双线验证

适合：平台团队、公共框架团队、拥有较强自动化测试体系的组织。

优点：

能同步评估短期稳定性与中期迁移成本；
更早暴露跨代兼容性问题；
有利于制定统一升级路线。

策略 C：如果必须长期停留 3.5，评估商业支持

适合：合规要求高、升级窗口长、系统耦合深的企业场景。

因为官方已经明确 3.5.x 的 OSS 周期结束在即，所以“长期停留但不做支持兜底”会越来越被动。

九、给团队负责人的建议

如果你是技术负责人、架构师或中台维护者，我更建议把这次发布当成一个版本治理节点，而不是一次普通补丁升级。

你可以在本周内完成三件事：

把所有 3.5.x 服务统一到 3.5.16；
拉出仍按名称依赖 taskExecutor、依赖宽松布尔配置、依赖旧 profile 命名习惯的模块清单；
明确 4.0 / 4.1 的迁移时间表与负责人。

这样做的好处是，你不会在 3.5 OSS 窗口结束后，仍把版本决策停留在“以后再说”。

十、总结

Spring Boot 3.5.16 表面上只是一次小型维护发布，但它的意义并不小：

它是 Spring Boot 3.5.x 的最后一个 OSS 发布版本；
它把 Spring AMQP 3.2.12、Spring Data BOM 2025.0.13、Spring Integration 6.5.10 纳入最终补丁基线；
它适合作为仍在 3.5 分支上的团队的最终稳定落点；
它也在提醒你：该开始准备 4.x 了。

如果你今天只能做一件事，那就先把测试环境升到 3.5.16，跑完关键回归，再安排生产发布窗口。对仍处在 3.5 生命周期尾段的系统来说，这是成本最低、收益最高的一步。

Spring Boot 4.0 正式发布后该怎么升级：核心变化、兼容性影响与实战建议

Mon, 29 Jun 2026 14:40:54 +0000

Spring Boot 4.0 已经正式 GA。对很多 Java 团队来说，这不是一次普通的小版本升级，而是一次带有明显“代际变化”特征的升级：底座切换到 Spring Framework 7，运行基线与依赖兼容性被整体抬高，同时也带来了更现代的工程能力。

如果你关心的问题是“Spring Boot 4.0 到底带来了什么”“现有项目升不升、怎么升、坑在哪”，这篇文章会从已公开的官方信息出发，梳理它的核心变化、升级影响以及更稳妥的落地路径。

Spring Boot 4.0 现在处于什么状态

从 Spring 官方博客可以确认，Spring Boot 4.0.0 已于 2025-11-20 正式发布，并且已经可以从 Maven Central 获取。与此同时，Spring 官方文档站已经提供 4.0.x 文档线，这说明 4.0 不再是预览版，而是进入了正式维护周期。

这意味着对于已经在 3.x 稳定运行的团队来说，现在讨论的重点已经不再是“能不能尝鲜”，而是“是否值得安排升级窗口，以及怎么降低升级风险”。

为什么说 Spring Boot 4.0 是一次代际升级

Spring 官方对 4.0 的定调非常明确：它是构建在 Spring Framework 7 之上的新一代 Spring Boot。

这句话的分量很重。因为这意味着它不只是新增几个 starter 或者小幅改造自动配置，而是整个技术基线都随之上移。很多团队在迁移时遇到的问题，根源并不在 Boot 自身，而是出在与之配套的 Java 版本、Servlet 基线、第三方依赖、容器选择和老旧 API 使用方式上。

换句话说，Spring Boot 4.0 的价值和成本都比常规次版本升级更高：

价值在于它把 Spring 生态带入了新的工程阶段；
成本在于你必须把项目的“底层地基”一起升级。

Spring Boot 4.0 的核心变化有哪些

1. 基于 Spring Framework 7

这是所有变化的起点。Spring Boot 4.0 不是孤立演进，而是直接建立在 Spring Framework 7 之上。

对于开发者来说，这意味着：

Spring 体系下的一些长期演进点会在 4.0 更集中地体现出来；
与 Framework 7 绑定的兼容性要求会直接影响 Boot 项目；
周边生态是否支持 Spring Framework 7，会成为升级前必须核查的事项。

2. Spring Boot 代码库完成模块化重构

官方将其描述为 complete modularization of the Spring Boot codebase。这不是一个面向业务代码直接可见的“语法特性”，但它对框架演进很重要。

模块化重构带来的直接信号是：

Spring Boot 内部的职责边界更加清晰；
产物会朝着更小、更聚焦的 jar 方向演进；
对后续自动配置裁剪、维护成本控制和长期扩展更友好。

如果你所在团队很关注启动体积、依赖治理和框架透明度，这会是一个值得关注的变化。

3. Null Safety 增强，引入 JSpecify 方向的统一改进

官方明确提到，Spring Boot 4.0 在整个产品线范围内加强了 null safety，并采用 JSpecify 相关改进。

这类变化不会像一个新 starter 那样直观，但它会逐步影响：

IDE 的静态提示；
Java / Kotlin 混合工程中的空安全语义；
编译期和分析期对潜在 NPE 风险的暴露。

对老项目来说，这也意味着一些“以前没出事但本来就不安全”的写法，可能会在升级后更容易被工具识别出来。

4. Java 25 一等支持，同时最低仍要求 Java 17

Spring 官方对 Java 支持给出了非常清晰的说法：Spring Boot 4.0 对 Java 25 提供一等支持，同时继续兼容 Java 17。

从官方系统要求页还能进一步确认：

Spring Boot 4.0.x 最低需要 Java 17；
当前文档线显示其兼容范围可覆盖更高版本 Java；
它要求与 Spring Framework 7.0.x 配套使用。

这说明两件事：

如果你的项目还停留在 Java 11 或更低，升级 Boot 4.0 就不是单纯改依赖版本，而是一次 JDK 基线升级项目；
如果你已经在 Java 17 或更高版本上运行，那么迁移门槛会显著降低。

5. HTTP Service Clients 获得自动配置支持

Spring Boot 4.0 Release Notes 提到，它新增了 HTTP Service Clients 的自动配置支持与配置属性支持。

这类能力的价值在于：

可以通过接口式、声明式方式定义 HTTP 调用；
比手写一层层 WebClient / RestTemplate 包装更简洁；
更适合内部服务调用、SDK 化封装和接口契约式开发。

如果你的系统中已经存在大量对外部服务或内部微服务的 HTTP 调用，这部分能力值得重点关注，因为它能让调用层写法更现代、更一致。

6. MVC 与 WebFlux 获得 API Versioning 自动配置

Spring Boot 4.0 还正式引入了 API Versioning 自动配置，并同时支持：

Spring MVC
Spring WebFlux

这意味着 API 版本治理从“每个团队自己约定、自己封装”进一步走向“框架级支持”。

对于存在以下需求的系统，这个改动很有价值：

同时维护多个 API 版本；
对旧客户端进行平滑兼容；
需要在版本治理层面减少重复样板代码。

7. JMS 支持扩展到新的 JmsClient API

对于仍在使用 JMS 的企业应用场景，Spring Boot 4.0 的自动配置现在支持新的 JmsClient API，同时保持对 JmsTemplate 和 JmsMessagingTemplate 的兼容。

这意味着老系统不会被强迫一次性大改，但新接口能力已经被纳入官方支持范围，团队可以根据节奏逐步迁移。

8. TaskDecorator 组合能力增强

在任务执行和任务调度自动配置方面，Spring Boot 4.0 支持多个 TaskDecorator，并会将它们组合成 CompositeTaskDecorator。

这个变化对日常业务代码未必显眼，但对工程化能力很有帮助，尤其在这些场景下：

链路追踪上下文透传；
日志 MDC 传递；
租户上下文封装；
审计信息注入。

对于对异步任务治理比较重视的团队，这属于非常实用的增强。

9. 新增 OpenTelemetry starter

Spring Boot 4.0 新增了 spring-boot-starter-opentelemetry，并会自动带入面向 OTLP 的指标与链路导出依赖，同时自动配置 OpenTelemetry SDK。

这释放出一个非常明确的信号：

Spring Boot 在可观测性方向上，正进一步向 OpenTelemetry 标准体系靠拢。

如果你的系统正在推进云原生可观测性，或者已经使用统一的 metrics / traces 采集链路，那么 4.0 会比过去更顺手。

10. Gradle 9 支持

官方 Release Notes 明确确认：

Spring Boot 4.0 支持 Gradle 9；
同时继续支持 Gradle 8.14+；
Maven 方面要求 3.6.3+。

如果你的项目使用 Gradle，并且一直想与新版本构建链路保持同步，4.0 在这方面给出了比较明确的支持保证。

升级到 Spring Boot 4.0 时真正需要注意什么

对于大多数团队来说，真正决定“能不能顺利升级”的，不是新特性，而是下面这些兼容性影响。

1. 官方建议：先升到最新 3.5.x，再升 4.0

Spring 官方 Release Notes 和 Migration Guide 都明确建议：

如果你当前项目还不在 3.5.x，最好先升级到最新 3.5.x，再迁移到 4.0。

这是一个非常实用的建议。

因为跨越多个大/小版本直接跳到 4.0，意味着你会同时面对：

旧依赖问题；
废弃 API 问题；
配置属性变更问题；
底层基线问题。

而如果先对齐到 3.5.x，再迁移到 4.0，很多问题会更容易分层定位。

2. Java、Kotlin、GraalVM、Servlet 基线整体抬升

官方 Migration Guide 给出的迁移基线包括：

Java 17+
Kotlin 2.2+
GraalVM native-image 25+
Jakarta EE 11
Servlet 6.1 baseline

这意味着，如果你的项目还有这些历史包袱：

老 JDK；
低版本 Kotlin；
旧 native-image 构建链；
旧 servlet 容器；
对 Jakarta 升级准备不足；

那么升级 Boot 4.0 的工作量会比“改 pom 版本号”大得多。

3. Undertow 支持被移除

这是 4.0 升级里最容易被忽略、但实际影响很大的点之一。

官方 Migration Guide 明确指出：由于 Spring Boot 4.0 需要 Servlet 6.1 baseline，而 Undertow 当前不兼容这一基线，因此 Boot 4 移除了 Undertow 支持。

这包括：

Undertow starter
作为嵌入式服务器的 Undertow 能力

如果你的应用当前使用 Undertow，那么升级到 4.0 时必须评估迁移到：

Tomcat 11.0.x
Jetty 12.1.x

这不是一个可忽略的 warning，而是明确的支持移除。

4. Spring Boot 3.x 中已废弃的类、方法、配置，在 4.0 中可能已经删除

官方 Migration Guide 明确说明：Spring Boot 3.x 中标记为 deprecated 的 classes、methods、properties，在 4.0 中已经被删除。

这会带来几类典型问题：

编译失败；
启动失败；
配置项失效但不一定立即显眼；
某些集成测试才暴露行为变化。

所以在升级前，最好先把当前项目里所有 Boot 3.x 已知的 deprecated 用法清理一遍，不要把这些历史债务带进 4.0。

5. 配置属性迁移建议使用 `spring-boot-properties-migrator`

对于配置项重命名或移除问题，官方建议可以在升级阶段临时引入：

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-properties-migrator</artifactId>
 <scope>runtime</scope>
</dependency>

这个工具的作用是：

在启动时分析环境配置；
打印属性迁移相关诊断信息；
对部分已改名属性提供运行时迁移帮助。

但要注意两点：

它只是迁移辅助工具，不是长期依赖；
迁移完成后应该移除。

6. 第三方依赖兼容性比 Boot 自身更值得重点检查

官方迁移建议中特别提到，要对比 3.5.x 与 4.0.x 的 dependency management，并重点检查非 Boot 管理的依赖。

这在真实项目里非常关键。因为很多升级失败案例并不是 Spring Boot 本身出问题，而是下面这些组件没有及时跟上：

Spring Cloud 对应版本；
第三方 starter；
安全、监控、消息队列等中间件整合包；
自定义 BOM；
直接锁定版本的 Jakarta / servlet 生态库。

所以在升级方案上，最稳妥的方式是把“依赖兼容性核查”当作单独工作项来做，而不是在 CI 报错后再被动补救。

一条更稳妥的 Spring Boot 4.0 升级路径

如果你准备在生产项目中升级到 Spring Boot 4.0，可以参考下面这条更稳妥的路径：

第一步：先把项目升级到最新 Spring Boot 3.5.x

这样做的目的不是浪费时间，而是先把 3.x 线上的兼容问题清干净，降低跨代升级风险。

第二步：清理所有已知 deprecated API 与配置

重点排查：

启动日志中的 deprecated 提示；
配置文件中的旧属性；
自定义 starter 或公共组件里的旧用法。

第三步：确认技术基线满足 4.0 要求

至少要确认：

JDK 是否已到 17+；
Kotlin / GraalVM 是否需要同步升级；
容器是否使用 Undertow；
是否依赖老 Servlet 规范。

第四步：核查外围依赖与 Spring Framework 7 / Boot 4 的兼容性

这一步尤其适合通过依赖树、BOM 对比、第三方 starter 发布说明来完成。

第五步：必要时临时引入 `spring-boot-properties-migrator`

把它当作迁移辅助，而不是长期依赖。

第六步：做完整的回归验证

需要重点回归的通常包括：

Web 层接口兼容性；
安全配置；
配置绑定；
任务调度 / 异步执行；
消息队列集成；
监控与链路追踪；
原生镜像构建（如果你在用）。

Spring Boot 4.0 值不值得升

如果你的项目还处于以下状态：

仍在 Java 11 或更老版本；
依赖大量历史包袱；
使用 Undertow 且短期不愿迁移；
对升级窗口极度敏感；

那么短期内不一定适合马上升级到 4.0。

但如果你的项目已经：

运行在 Java 17+；
对可观测性、声明式 HTTP 客户端、API 版本治理等能力有明确需求；
希望尽早跟上 Spring Framework 7 的长期演进路线；
愿意安排一次成体系的升级与回归；

那么 Spring Boot 4.0 是值得认真评估并纳入计划的。

它的意义不只是“版本更高了”，而是它开始把 Spring Boot 带到一个更现代的工程基线上：更清晰的模块边界、更明确的技术底座、更统一的可观测性与 API 治理能力，以及对新一代 Java 的更完整支持。

总结

Spring Boot 4.0 的核心价值可以概括为三点：

它是基于 Spring Framework 7 的代际升级；
它在工程能力上继续向现代化靠拢，尤其是 HTTP Service Clients、API Versioning、OpenTelemetry 与任务装饰能力；
它的升级成本主要来自底层基线提升与旧能力移除，尤其是 Undertow 支持下线、Java/Servlet/Jakarta 体系全面抬升。

对团队来说，最好的做法不是盲目追新，也不是长期停留在旧版本，而是根据自己的技术债水平与业务窗口期，选择一个可控的节奏完成升级。