Spring Boot 3.5结束开源支持：官方建议迁移至4.x

Spring Boot 3.5.x分支的开源免费支持, 在2026年6月25日正式终止。官方推出的3.5.16, 是此分支最后一个开源版本, 之后安全更新以及缺陷修复, 将不会再按照原本节奏推送。这样的变化, 直接对大量仍在运行3.5.x的生产系统产生影响, 企业需要重新去评估维护策略和迁移计划。

支持策略变化

官方清晰表明, 3.5.x这个分支, 不再依照原本的开源维护节奏。尽管3.5.16存有三项, 依赖升级的情况, 然而这并不代表后续, 必然还会有全新的免费补丁发布。生产环境里的风险在于, 未来新披露出来的安全漏洞, 不一定会得到面向3.5.x的免费修复方案。

主要版本起码得对三年予以支持, 不过其前提在于运用的是仍处在支持期范围之内的小版本。小版本起码支持十二个月时间长度, 补丁版本是依据实际所需来予以发布的。这样一个策略方面面临的变化状况要求开发团队务必要重新去仔细审视当下项目的维护边界以及长期存在的风险。

潜在迁移风险

持续运用3点5点16的应用依旧能够依照现有的方式去构建以及运行, 已有的二进制包不会出现失效的情况。然而风险在于后续维护的界限已然发生了改变, 开发团队需要去盘点生产环境里的Boot小版本、Java版本、生态依赖以及第三方组件。仅仅检查项目根目录的版本号是远远不足够的。

父工程, 以及依赖管理平台, 包括构建镜像, 还有内部组件, 都有把应用锁定在3.5.x分支的可能性。团队要对技术栈进行全面整理, 去确认有没有隐藏的版本依赖, 防止因为局部的升级致使整个系统的不稳定。

升级路径建议

朝着4.x从3、5、16迁移这般情况, 是绝不能被看作寻常补丁升级的。项目得去查看目标分支那儿, 有关迁移的指南, 还有发布说明, 以及那个配置变更记录来着。自动配置这一块儿, 测试切片这一方面, 序列化这种情况, 数据库访问这一范畴, 以及那个构建插件这一领域, 通通都得去做回归验证, 以此来保证功能兼容性。

以Spring Cloud为依托的系统, 以Data作为使用对象的系统, 依赖信号传递中间件的系统, 跟依靠数据库驱动的系统之中, 都一定要再次核查相关发布列车和Boot目标版本有没有相互匹配。跨越不同版本进行升级所关联到的技术复杂性程度比较高, 就此在进行时建议按照不同的阶段渐次推进。

短期应对方案

团队若短期无法迁移, 至少要将分支状态写入风险清单，持续关注官方安全公告。组织需确认是否具备商业支持或其他补救安排。版本支持范围以及商业支持期限和后续迁移建议, 可能会继续调整, 而最终判断应以官方支持页面以及目标版本说明为准。

对于那些有着需延长维护周期需求的组织而言, 官方是给出了另行评估购买商业支持这样的建议的。商业支持能够提供时长更久的维护窗口, 以及具备优先特性的技术响应情况, 适合那种对于稳定性有着较高要求的生产环境。

版本选择参考

可供学习框架结构的Spring Boot 3.3.13官方源码, 适合自动配置机制, 也适合依赖管理以及生产级Java应用开发。这一版本的代码, 结构清晰, 是可用于理解框架设计原理的良好参考。

3.5.16适宜当作3.5.x项目的收尾基线, 然而却不应该被错误理解成新的长期免费维护入口, 团队应当把它看成过渡版本, 而不是长期所依赖的技术栈。

技术验证建议

先增添一条 4.x 验证分支于持续交付流水线之中, 去对比启动日志, 以及集成测试情况, 还有容器镜像情形, 以及健康检查状况, 和关键接口结果。借由并行验证能够提前发觉兼容性问题，然后再去确定正式切换的时间。

技术团队需要创设完整健全的升级验证清单, 并将功能测试、性能测试以及安全扫描一并涵盖在内。唯有在验证结果全然契合预期之后, 才可进行生产环境的正式切换, 方可敲定安排。

而今你这个项目当下正运行于何许Spring Boot版本, 究竟有没有已然制定了向4.x迁移的计划, 欢迎去评论区域分享你积累的经验以及遇见的挑战。