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

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 生命周期尾段的系统来说，这是成本最低、收益最高的一步。