I IDEAICU

Backend Engineering

Spring Boot 3.5.16 是 3.5.x 最后一个 OSS 版本：存量项目现在该怎么升

Spring Boot 3.5.16 已发布，可从 Maven Central 获取。就变更规模看，这不是一个会让团队大动干戈的版本：重点只是少量依赖升级。真正重要的是它的生命周期信号——这是 Spring Boot 3.5.x 这一代最后一个 OSS release。

这句话对存量 Java 项目的意义，比“又发了一个版本”大得多。它不等于所有 3.5.x 应用明天都会出问题，也不等于必须立刻把生产系统切到 Boot 4。但它意味着团队不能再把大版本迁移评估无限期后延。后续生态、文档、社区经验、安全修复节奏和新能力适配，都会越来越向 Spring Boot 4.x、Spring Framework 7 以及新的依赖基线集中。

先把问题拆成两件事

最容易犯的错误，是把“升到 3.5.16”和“迁移到 4.x”混成同一个任务。前者更像维护动作，目标是把当前 3.5.x 分支收口到最稳的公开版本；后者是大版本迁移，需要完整评估依赖、配置、测试、部署和观测链路。

  • 短期动作：把仍在 3.5.x 的项目升级到 3.5.16，跑完现有测试和部署验证。
  • 中期动作：另开分支评估 Spring Boot 4.0.x 或 4.1.x，不要直接在主干上试探性改版本。
  • 长期动作：把 JDK、Spring Cloud、Security、Data、Micrometer、Reactor、构建插件和镜像链路作为一个组合来管理。

这样拆分后，团队可以先消除 3.5.x 收尾版本带来的维护缺口，再用可回滚、可对比的方式推进 Boot 4 迁移。

哪些项目可以直接看 4.1

新项目没有必要再落到已经收尾的 3.5.x 分支上。尤其是准备接入 Spring AI、Agent 工作流、RAG、MCP、OpenTelemetry、gRPC 或更完整云原生观测能力的项目，直接从 Boot 4.1 开始会更干净。新的示例、依赖组合和问题讨论会越来越围绕 4.x 发生，越晚进入，越容易在老分支上做重复适配。

存量项目则不要简单套用这个结论。只要系统有复杂的安全配置、数据访问层、自定义 starter、老旧第三方库、Native Image/AOT、或者多模块构建，直接改版本号往往只会把问题拖到运行期。稳妥做法是先让 3.5.16 分支稳定，再为 Boot 4 单独建立升级分支。

Boot 4 迁移前的检查清单

大版本升级不能只看应用能否启动。启动成功只能说明最表层的配置没有立刻炸掉，不代表行为一致、性能一致、观测有效、上线可控。至少应检查这些点：

  • 当前 JDK 版本是否满足新基线，CI、Docker 基础镜像、本地开发环境是否一致。
  • Spring Framework 7 相关 API、注解、自动配置机制和第三方 starter 是否兼容。
  • Spring Security 的过滤链、授权规则、默认行为和测试辅助工具是否变化。
  • Spring Data、事务、连接池、ORM、数据库驱动是否需要成组升级。
  • Spring Cloud 项目是否有对应 release train，不要只升级 Boot 而忽略云组件兼容矩阵。
  • Micrometer、日志、链路追踪、指标导出、告警面板是否仍然能覆盖关键路径。
  • Testcontainers、构建插件、代码生成、AOT、Native Image、Docker 镜像构建是否能在 CI 中稳定复现。

推荐的升级节奏

对大多数团队来说，可以按四步走。

  1. 先升到 3.5.16。修改版本后检查依赖树，跑单元测试、集成测试、关键接口回归和镜像构建。这个阶段不引入无关重构。
  2. 建立 Boot 4 迁移分支。把 Boot、Framework、Security、Data、Cloud、Micrometer、Reactor 等依赖作为一组处理，记录每一次不兼容修改。
  3. 按层验证。先编译，再单测，再集成测试，再核心业务场景，再部署链路，最后看观测数据。不要把所有失败混在一个大回归里。
  4. 写升级记录。记录升级前后版本、关键配置改动、替换的第三方依赖、测试覆盖范围、上线观察指标和回滚方案。

这份记录不是形式主义。多服务团队迟早会遇到第二个、第三个类似项目，有了第一份升级账本，后面的迁移成本会明显降低。

和 Spring AI 2.0 的关系

Spring AI 2.0 已经面向 Spring Boot 4.0/4.1 和 Spring Framework 7 的新基线设计。如果团队今年要在 Java 技术栈里做 AI 应用、Agent、RAG 或模型接入，Boot 4 不再只是“以后再说”的平台升级，而是会直接影响新能力选型的基础条件。

因此，3.5.16 的正确打开方式不是恐慌升级，而是建立节奏：当前生产分支先稳定在 3.5.x 最后公开版本，新能力和中长期演进尽快进入 4.x 验证。等到安全、依赖、文档和社区经验都已经明显偏向 4.x 时，再启动迁移就会被动得多。

结论

Spring Boot 3.5.16 的技术变更不大，但发布节点很关键。仍在 3.5.x 的项目应该尽快完成收尾升级，同时把 Boot 4 迁移评估排上计划。不要把维护补丁做成大迁移，也不要把大迁移拖成技术债。最稳的路线，是先收口，再分支验证，再按业务风险逐步上线。