Spring 生态能够在近二十年的时间里保持活力，与其清晰、克制的版本演进策略密不可分。每一个大版本的升级，都不是简单的功能堆砌，而是针对当时的主流技术趋势、Java 平台发展以及业界实践进行的有决断力的重构与现代化。理解这段演进历程，有助于你更好地把握当前技术栈的定位，也能更从容地应对未来的升级。
1.4.1 Spring Framework 5.x：响应式与现代化的奠基
Spring Framework 5.0 于 2017 年发布，是一次面向 Java 8+ 时代的彻底重构，它奠定了后续所有上层项目的基石。
1. 全生命周期响应式支持（WebFlux）
5.x 最核心的变革，是引入了基于 Reactor 的响应式编程模型。核心模块 spring-webflux 提供了与 Spring MVC 并列的、完全异步非阻塞的 Web 框架，可以与 Netty、Undertow 等非 Servlet 容器一起运行，也为后来 Spring Cloud Gateway 的出现铺平了道路。这一变化直接影响了高并发网关、流数据处理等场景的架构选择。
2. Java 8 成为底线，函数式编程广泛渗透
框架内部代码全面拥抱 Lambda、Optional、函数式接口，同时引入了函数式风格的 Bean 注册方式（GenericApplicationContext 的 registerBean 方法），以及 Router Function 来替代 @RequestMapping 的另一种可能性。这使得代码更加简洁，也为 Kotlin 等 JVM 语言的一等支持提供了底层基础。
3. 核心容器的增强
- 支持
@Nullable注解：加强空安全表达，并利用注解提示工具检查。 - 日志体系统一到 SLF4J：自行实现
spring-jcl桥接，不再直接依赖 commons-logging。 - 基于 Java 的配置全面替代 XML：
@Configuration结合@Bean成为事实标准，大部分开发者几乎无需再接触 XML 配置文件。
4. 测试模块的改进
引入了 WebTestClient 用于测试 WebFlux 应用，并且 Spring Test 的上下文缓存、事务测试等方面的性能得到了显著优化。
1.4.2 Spring Framework 6.x：拥抱新时代的基线升级
Spring Framework 6.0 于 2022 年随 Spring Boot 3.0 一起发布，标志着 Spring 生态再次进行了一次面向未来十年的平台重置。
1. JDK 17 作为最低要求，全面拥抱新特性
6.x 要求 Java 17 以上运行，这是自 5.x 要求 Java 8 以来最大的一次基线提升。这意味着所有 Spring 应用默认获得了密封类、记录类、模式匹配、文本块、增强随机数生成等现代语言特性的支持。框架自身大量运用了这些特性，例如配置属性现在已经普遍基于 record 类进行绑定。
2. Jakarta EE 9+ 迁移：最大的命名空间变更
这是 Spring 6 最具破坏性但也最必要的变更。Java EE 演进为 Jakarta EE 后，所有 javax. 包名变更为 jakarta.。Spring 6 及 Spring Boot 3 全面适配了这个变化。如果你还在使用传统的 javax.servlet、javax.persistence，升级时需要进行全项目范围的包替换，好在许多 IDE 和工具已提供半自动迁移能力。
3. GraalVM 原生镜像与 AOT 编译
Spring 6 内置了 AOT（Ahead-of-Time）处理引擎，能够在构建时分析你的应用，生成预先编译的原生镜像配置与优化后的字节码。这让 Spring 应用可以用极低的启动时间和内存占用运行在 GraalVM 原生镜像中，非常适合 Serverless 和容器环境。这一能力通过 Spring Boot 3 的 spring-boot-maven-plugin 或 gradle-plugin 直观地暴露出来。
4. 移除过时模块，技术栈更加精简
移除了不再符合现代架构的模块，例如 Portlet、JRuby 支持，同时放弃了对旧式 XML 配置的部分遗留支持，进一步巩固了基于 Java Config 的标准模型。
1.4.3 Spring Boot 2.x：约定优于配置的成熟期
Spring Boot 2.0 基于 Spring Framework 5.x 构建，目标是让“开箱即用”的体验进一步升华。
1. 自动化配置的升级
自动配置类全面改为使用 @Conditional 派生注解，更灵活地控制 Bean 的装配条件。同时，application.properties 与 YAML 支持的配置属性达到了上千项，覆盖了主流中间件的绝大部分参数设定。
2. Actuator 重构与可观测性增强
Actuator 端点被重新设计，引入独立的 health、info、metrics 端点，并原生支持 Prometheus 指标输出。Micrometer 作为度量门面被无缝集成，替代了内部实现的指标系统。
3. Web 运行时多样化
除了内嵌 Tomcat，Boot 2.x 对 Undertow 和 Jetty 的支持同样成熟，同时将 WebFlux 模式提升为与 Servlet 模式同等重要，可以自由切换。
4. 安全与数据默认配置的调整
默认启用 CSRF 保护，定制了更安全的错误页面处理。并且为基于 JPA、Redis、MongoDB 的 starter 提供了更智能的连接检测，减少了启动失败的概率。
1.4.4 Spring Boot 3.x：面向云原生与现代化
Spring Boot 3.0 基于 Spring Framework 6.x，做出了一系列响应云原生需求的关键变革。
1. 默认 Java 17，原生镜像优先
与 Framework 对齐，强制 Java 17。原生镜像支持从实验性功能变成一等公民，官方文档和插件指南都以此为重点方向。spring-boot-starter 自身的类库也针对 GraalVM 进行了全面适配。
2. 全面转向 Jakarta EE 9
这是从 Boot 2 升级到 3 最明显的差异。所有依赖 javax 的 starter（如 spring-boot-starter-web、spring-boot-starter-data-jpa）已经自动带入了 Jakarta 版本。如果不慎混用旧的 javax 库，启动时会直接失败，这种明确的错误提示虽然生硬，却避免了潜在的运行时异常。
3. 可观测性的大一统：Micrometer 增强与追踪支持
Boot 3 将 Micrometer 从单纯的指标统计扩展到了分布式追踪领域。通过 Micrometer Tracing，桥接 Brave 或 OpenTelemetry，应用可以方便地将追踪数据发送到 Zipkin 或 Jaeger，而无需额外依赖 Sleuth（Sleuth 已与 Micrometer Tracing 合并）。这使得可观测性的三大支柱——日志、指标、追踪——在同一个 API 门面下得到了统一。
4. Spring Security 的简化配置
引入了 SecurityFilterChain 的 Bean 风格配置，废弃了老的 WebSecurityConfigurerAdapter，让安全配置更加函数式和直观。同时兼容 OAuth2 1.0 相关的旧代码被移除，全面拥抱 OAuth2 和 OpenID Connect。
5. 性能与开发者体验提升
- 更快的启动速度：得益于内部缓存优化与 AOT 预处理。
- Spring Boot DevTools 的热重启现在与原生镜像不冲突，开发体验更一致。
- 更好的错误消息：在配置绑定失败或 Bean 依赖缺失时，提供的描述更加精确，能准确定位到属性名或类名。
1.4.5 实际升级的考量
对于新项目，直接从 Spring Boot 3.x + Java 17 起步是最佳选择，能享受到所有现代化特性和性能红利。而对于仍在维护的 Spring Boot 2.x 系统，是否升级应权衡以下几点：
- 是否有强制性安全或性能需求：3.x 会持续获得关键补丁，而 2.x 的免费支持窗口已关闭（商业支持除外）。
- 依赖生态是否就绪：如果系统中用到的第三方库还未提供
jakarta版本，升级就会受阻。但目前主流中间件客户端都已适配。 - 团队学习成本：包名替换虽然繁琐，但逻辑没有根本变化，通常是“一次性的阵痛”。
温和的建议是：在新模块中率先使用 3.x，将旧系统逐步剥离重构，避免一次性的“大爆炸”升级。Spring 生态的版本演进，始终遵循着“一个可预期的现代化节奏”——每隔几年完成一次平台重置，同时最大化地保留开发者已有的知识与经验。这正是 Spring 得以持续引领 Java 企业开发的重要原因。