摘要：本文深入解读 Spring Framework 官方文档关于历史背景与设计哲学的阐述，剖析 Spring 与 Jakarta EE 的互补关系、javax 到 jakarta 的命名空间升级，以及从应用服务器到嵌入式容器的范式转移，帮助开发者理解 Spring 6 / Spring Boot 3 乃至 Spring 7 的底层逻辑与演进方向。

---

1. 引言：Spring 的二十年

2003 年，Rod Johnson 带着《Expert One-on-One J2EE Design and Development》和 Spring Framework 1.0，向当时如日中天却异常复杂的 J2EE 体系发起了挑战。彼时的企业级 Java 开发，EJB 2.x 是“标配”，但也是无数开发者的噩梦——复杂的部署描述符、重量级的容器依赖、难以测试的业务逻辑。

Spring 提出的“轻量级容器”和“依赖注入（DI）”理念，如同一股清流，让开发者可以用 POJO 编写业务逻辑，极大地降低了开发门槛。二十年后的今天，Spring 已成为 Java 企业级开发的事实标准，而它成功的关键，恰恰在于始终与时代同频，不断演进，但从不背离“简化企业应用开发”的初心。

---

2. Spring 与 Jakarta EE：不是对手，而是搭档

一个常见的误解是：Spring 要取代 Java EE / Jakarta EE。官方文档对此给出了明确的回应：

“While some consider Java EE and its modern-day successor Jakarta EE to be in competition with Spring, they are in fact complementary.”

Spring 并没有试图“另起炉灶”去实现一套完整的企业级规范，而是采取了**“为我所用，精挑细选”**的策略。它从庞大的 EE 规范体系中，遴选出真正被广泛实践验证的子规范，将其无缝集成到 Spring 编程模型中：

• Servlet API：Web 层的基石
• JPA：对象关系映射标准
• Bean Validation：数据校验规范
• JMS：消息中间件标准
• Concurrency Utilities：并发工具

这种“乐高式”的集成，让开发者可以按需选择，不必被沉重的全栈规范所束缚。Spring 拥抱了 EE 生态，但把选择权交还给了开发者。

---

3. 生死攸关的升级：从 javax 到 jakarta

2018 年，Oracle 将 Java EE 移交给 Eclipse 基金会，并更名为 Jakarta EE。由于 Oracle 在移交时保留了 javax 的商标权，Eclipse 基金会不得不将新规范的 API 包名全部从 javax.* 变更为 jakarta.*。这成为了 Java 生态近十年来最重大的一次底层变更。

Spring Framework 6.0 做出了一个果断的决定：将基线升级至 Jakarta EE 9 级别。这意味着：

• 所有 javax.servlet、javax.persistence、javax.validation 等包名，全部替换为 jakarta 前缀。
• 应用服务器 / Servlet 容器必须升级到对应版本：Tomcat 10.1+、Jetty 11+、Undertow 2.3+。
• 与之配合的 Hibernate ORM 也需升级至 6.1+。

这对开发者意味着什么？

如果你计划升级到 Spring Boot 3 或 Spring Framework 6，代码层面的包导入修改是不可避免的。虽然过程略显繁琐，但工具链（如 OpenRewrite）已经可以自动化完成大部分迁移工作。更重要的是，这次升级让 Spring 站在了 Jakarta EE 演进的最前沿，为后续支持 EE 10 及更新版本铺平了道路。

值得一提的是：随着生态的持续演进，Spring Framework 7.0 已于 2026 年初正式发布（当前最新版本为 7.0.4），继续引领着企业级 Java 的开发方向。Spring 7 在 Jakarta EE 10 基线之上，进一步拥抱了 Java 21+ 的语言特性与虚拟线程等新能力，推动企业级 Java 迈向新的高度。

---

4. 云原生的基石：从胖服务器到嵌入式容器

回顾历史，J2EE 时代的应用必须被打包成 WAR/EAR，部署到 WebLogic、WebSphere 等“重型”应用服务器上。这种模式在云计算时代显得笨重且低效。

Spring Boot 彻底改变了这一局面。它将 Servlet 容器（如 Tomcat、Jetty）嵌入到应用本身的 Jar 包中，使得应用可以作为一个独立的进程运行。

“applications are created in a devops- and cloud-friendly way, with the Servlet container embedded and trivial to change.”

这种“可执行 Jar”的模式，完美契合了不可变基础设施和 DevOps 理念。开发者构建出一个包含所有依赖的 Jar 包，在任何环境中用 java -jar 即可启动，环境差异被压缩到最小。

更进一步，Spring 5 引入了 WebFlux，这是一种基于响应式流（Reactive Streams）的 Web 框架，它不再直接依赖 Servlet API，可以运行在 Netty 等非 Servlet 容器之上。官方文档中对此的表述极为精准：

“a WebFlux application does not even use the Servlet API directly and can run on servers (such as Netty) that are not Servlet containers.”

这里的“不直接”一词颇值得玩味——WebFlux 在某些特定场景下（如为了兼容某些旧有组件或部署在特定容器中时）仍然可以运行在 Servlet 容器上，只是它“不需要”且“不直接”依赖它。Spring 正在突破传统 Java Web 的边界，拥抱更加异构和高性能的网络编程模型。

---

5. 不止于 Framework：繁荣的 Spring 生态

最后，我们需要认识到：Spring Framework 是整个生态系统的基石，但远非全部。Spring 团队围绕它构建了庞大的“家族产品”：

• Spring Boot：自动配置，快速启动
• Spring Security：强大的安全防护
• Spring Data：统一的数据访问抽象
• Spring Cloud：微服务治理全家桶
• Spring Batch：高效批量处理
• Spring Cloud Stream：消息驱动的微服务

每个项目都在独立演进，拥有自己的版本发布节奏和代码仓库。开发者可以通过 spring.io/projects 了解全貌，并根据项目需求选择合适的技术组合。

---

6. 结语

回望 Spring 二十年的发展历程，它之所以能够长盛不衰，核心在于**“顺势而为，借力打力”**：

• 面对复杂的 J2EE，它没有另立标准，而是用更轻量的方式集成规范。
• 面对 Jakarta EE 的包名变更，它果断升级基线，始终保持前沿兼容性。
• 面对云原生和 DevOps 的浪潮，它借助 Spring Boot 和 WebFlux 重新定义了应用交付方式。

从 2003 年到 2026 年，Spring 已经走过了二十余年的历程。从最初的轻量级容器到如今的响应式、云原生、模块化全面支持，Spring 始终保持着旺盛的生命力。理解这些背景，不仅能帮助我们更好地应对每一次技术升级，更能让我们在技术选型时，读懂 Spring 团队每一次变革背后的深思熟虑。

---