Spring 全景:从起源到 Spring 6 一文打通 IoC / AOP / 发展史
TL;DR
- 场景:Java 后端开发者系统梳理 Spring 框架的核心概念(IoC、AOP)与版本演进
- 结论:Spring 以 IoC + AOP 为工程化基础,已发展出 Spring Boot/Cloud 等完整生态;Spring 6 标志进入 Java 17 + Jakarta EE + 云原生时代
- 产出:1 份带版本矩阵与错误速查卡的 Spring 入门地图

版本矩阵
| 功能 / 版本 | 状态 | 说明 |
|---|---|---|
| Spring 1.0 首个正式版 | ✅ 已验证 | 2004 年 3 月发布(来源:springframework 官方历史、csdn Spring 介绍) |
| Spring 2.0 引入 XML Schema 命名空间 | ✅ 已验证 | 2006 年 10 月 3 日 GA(来源:Spring 官方公告 CSDN 转载) |
| Spring 3.0 基于 Java 5 + SpEL | ✅ 已验证 | 2009 年 12 月发布(来源:InfoQ Spring 3.0 报道、博客园存档) |
| Spring 4.0 支持 Java 8 + WebSocket | ✅ 已验证 | 2013 年 12 月发布(来源:Pivotal 官方公告、CSDN 洪墨水) |
| Spring 5.0 引入 WebFlux 响应式 | ✅ 已验证 | 2017 年 9 月 28 日发布(来源:InfoQ Spring 5 报道) |
| Spring 6.0 Java 17 + Jakarta EE 9+ | ✅ 已验证 | 2022 年 11 月 16 日 GA(来源:spring.io/blog/2022/11/16 官方公告) |
| Spring 6.0.13 维护版 | ✅ 已验证 | 2023 年 10 月 12 日发布,含 34 项修复(来源:spring.io 官方公告) |
| Spring Boot 1.0 | ✅ 已验证 | 2014 年 4 月发布,基于 Spring 4.0(来源:CSDN、博客园多篇) |
| Spring Cloud 集成 Eureka/Ribbon/Hystrix | ⚠️ 部分已弃用 | 官方已推荐 Spring Cloud LoadBalancer 替代 Ribbon,Resilience4j 替代 Hystrix |
需要我修改的提示
- 原文"2003 年 Spring 框架的第一个版本发布"应改为"2004 年 3 月 Spring 1.0 正式发布"(2002 年是 Rod Johnson 出版书籍与提出理念,2003 年是 SourceForge 开源立项,第一个 GA 版本实际为 2004 年 3 月)。该信息为联网核查后的修正,保留与否由你决定。
文章正文
基本简介
Spring 是一个分层清晰的 Full-Stack(全栈)轻量级开源框架。它以 IoC 和 AOP 为核心,提供了 Spring MVC、事务管理、数据访问、测试支持等企业级开发能力,也能很好地整合 MyBatis、Hibernate、Redis、消息队列等常见第三方框架。
简单来说,Spring 的核心目标是:降低 Java 企业级开发的复杂度,让开发者把更多精力放在业务逻辑上,而不是重复处理对象创建、依赖管理、事务控制和资源释放等基础问题。
Spring 官方地址如下:
shell
https://spring.io/

发展历程
在 Spring 出现之前,Java 企业级开发中非常重要的一套技术是 EJB。1997 年 IBM 提出了 EJB 的思想,之后 EJB 逐步发展:1998 年 EJB 1.0 标准出现,1999 年 EJB 1.1 发布,2001 年 EJB 2.0 发布,2003 年 EJB 2.1 发布,2006 年 EJB 3.0 发布。
EJB 曾经是 Java 企业开发的重要方案,但早期 EJB 使用复杂、配置繁重、侵入性较强。Spring 正是在这样的背景下出现的,它希望用更轻量、更灵活的方式解决企业应用开发中的常见问题。
Spring 的起源(2002 年)
Spring 框架最初由 Rod Johnson 创建。2002 年,Rod Johnson 出版了《Expert One-on-One J2EE Design and Development》一书,书中提出了很多关于 Java 企业级开发的改进思想,其中就包括后来 Spring 框架的核心理念。
Spring 最初的目标并不是做一个庞大的全家桶,而是希望解决当时 Java 企业应用中过度复杂的问题,尤其是降低 EJB 带来的开发成本。
Spring 框架的诞生(2003 年)
2003 年,Spring 框架的第一个版本发布。它的核心目标是简化企业应用开发,让对象创建、依赖管理、事务控制等能力可以通过统一的框架完成。
Spring 早期最重要的特性包括:
- 控制反转(IoC):通过容器管理对象的创建和依赖关系。
- 依赖注入(DI):对象不再自己创建依赖,而是由容器注入依赖。
- 面向切面编程(AOP):将事务、日志、权限等横切逻辑从业务代码中拆分出来。
- 数据访问支持:简化 JDBC 和 ORM 框架的使用,减少模板代码。
Spring 2.0(2006 年)
Spring 2.0 于 2006 年发布,这个版本让 Spring 的功能更加成熟,主要改进包括:
- 增强 XML 配置能力,使 Bean 配置更灵活。
- 改进 AOP 支持,让切面编程更容易落地。
- 提升 Spring MVC 的能力,使其更适合 Web 应用开发。
- 开始更好地支持注解方式,减少部分 XML 配置。
Spring 3.0(2009 年)
Spring 3.0 于 2009 年发布,是 Spring 现代化过程中的重要版本,主要变化包括:
- 支持 Java 5 和 Java 6 的新特性,例如泛型、枚举、注解等。
- 增强 Spring MVC 对 RESTful Web 服务的支持。
- 引入 Spring Expression Language(SpEL),可以在配置中使用表达式。
- 改进类型转换、格式化和注解驱动能力。
Spring 4.0(2013 年)
Spring 4.0 于 2013 年发布,开始支持 Java 8,并加入了更多现代 Web 开发能力:
- 支持 Java 8 的部分新特性。
- 增加 WebSocket 支持,方便开发实时通信应用。
- 继续增强 RESTful Web 服务能力。
- 支持 Groovy,让开发者可以使用更灵活的脚本方式配置和扩展应用。
Spring 5.0(2017 年)
Spring 5.0 于 2017 年发布,是一个非常重要的版本,主要变化包括:
- 引入 Spring WebFlux,支持响应式编程模型。
- 全面支持 Java 8 及以上版本。
- 基于 Project Reactor 提供非阻塞、响应式 Web 开发能力。
- 开始正式支持 Kotlin。
- 对框架内部进行了较多重构,提升可维护性和扩展性。
Spring Boot(2013 年)
Spring Boot 是 Spring 团队为了简化 Spring 应用配置和部署推出的项目。它的目标是让开发者可以更快创建、运行和交付 Spring 应用。
Spring Boot 的主要特点包括:
- 自动配置:根据项目依赖自动完成常见配置。
- 嵌入式服务器:可以直接内嵌 Tomcat、Jetty 等服务器。
- 可执行 JAR:应用可以打包成一个独立运行的 JAR 文件。
- Spring Initializr:通过网页快速生成 Spring Boot 项目骨架。
Spring Boot 的出现大幅降低了 Spring 项目的入门成本,也让 Spring 更适合快速开发微服务应用。
Spring Cloud(2014 年)
Spring Cloud 是基于 Spring Boot 构建的一套分布式系统开发工具集,主要用于微服务架构。
它提供了一些常见的分布式系统能力,例如:
- 配置管理:通过 Spring Cloud Config 实现集中配置管理。
- 服务发现:早期常见方案包括 Eureka。
- 负载均衡:早期常见方案包括 Ribbon,后来逐渐被 Spring Cloud LoadBalancer 替代。
- 熔断与容错:早期常见方案包括 Hystrix,后来也逐渐被 Resilience4j 等方案替代。
需要注意的是,Spring Cloud 不是一个单独的框架,而是一组微服务相关组件和规范的整合。
Spring 6.0(2022 年)
Spring 6.0 于 2022 年 11 月 GA,是 Spring 进入现代化阶段的重要版本。它和 Spring Boot 3.x 关系非常紧密,主要变化包括:
- Java 17 基线:Spring 6.0 要求至少使用 Java 17。
- Jakarta EE 迁移:从原来的
javax.*迁移到jakarta.*命名空间。 - AOT 支持:增强 Ahead-of-Time 处理能力,为 GraalVM Native Image 提供更好的基础。
- 依赖升级:移除大量过时 API,升级底层依赖。
- 云原生适配:更适合 Kubernetes、容器化和现代云原生部署环境。
shell
https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga
网页内容如下:

shell
https://spring.io/blog/2023/10/12/spring-framework-6-0-13-available-now
网页内容如下:

Spring 优势
Spring 能够长期流行,核心原因在于它解决了 Java 企业级开发中的很多重复性问题。
- 方便解耦,简化开发:通过 IoC 容器管理对象之间的依赖关系,减少硬编码带来的强耦合。
- 支持 AOP 编程:可以把日志、事务、权限、监控等横切逻辑从业务代码中拆分出来。
- 支持声明式事务:通过
@Transactional管理事务,减少手动开启、提交、回滚事务的代码。 - 方便测试:Spring 提供了完善的测试支持,可以更容易地进行单元测试和集成测试。
- 方便集成其他框架:Spring 对 MyBatis、Hibernate、Redis、消息队列等常见技术都有良好的整合能力。
- 降低 Java EE API 使用难度:Spring 对 JDBC、JavaMail、远程调用等 API 做了封装,降低了使用成本。
- 源码具有学习价值:Spring 源码中大量使用了设计模式,是学习 Java 框架设计的重要参考。
核心结构
Spring 是一个模块化、分层清晰的框架。它主要包括核心容器、AOP、数据访问、Web、测试等模块。不同模块职责明确,又可以互相配合,共同支撑完整的企业级应用开发。

- Spring 核心容器(Core Container):这是 Spring 最核心的部分,负责 Bean 的创建、配置和管理。我们常说的 IoC、DI,主要就是由核心容器完成的。
- 面向切面编程(AOP):Spring 提供了 AOP 支持,可以在不修改业务代码的情况下增强方法逻辑,例如事务、日志、权限校验等。
- 数据访问与集成:Spring 对 JDBC、事务、ORM、OXM、JMS 等能力进行了封装,减少重复代码,并统一资源管理方式。
- Web 模块:Spring 提供了 Spring MVC 等 Web 开发能力,可以用于构建传统 Web 应用和 RESTful 接口。
- Test 模块:Spring 提供了测试支持,方便开发者编写单元测试和集成测试。
核心思想
IoC 和 AOP 并不是 Spring 首次提出的概念。在 Spring 出现之前,这些思想已经存在,但更多停留在理论层面。Spring 的价值在于:它把这些思想用工程化的方式落地到了 Java 企业开发中。
IoC
IoC 全称是 Inversion of Control,中文通常翻译为"控制反转"。它是一种设计思想,不是某一个具体技术。
在 Java 开发中,IoC 主要解决对象创建和对象依赖管理的问题。
传统开发方式中,如果类 A 依赖类 B,通常会在类 A 中直接 new 一个类 B 的对象。这样写虽然简单,但会让类 A 和类 B 强绑定,后续替换、测试和扩展都会变得困难。
IoC 思想下,对象不再由业务代码自己创建,而是交给 IoC 容器统一创建和管理。应用需要某个对象时,由容器负责提供。

IoC 解决了什么问题
IoC 主要解决的是对象之间的耦合问题。
当对象由自己创建依赖对象时,代码之间会产生强依赖。使用 IoC 之后,对象只需要声明自己需要什么依赖,具体创建和装配过程交给容器完成。
这样可以带来几个好处:
- 降低类与类之间的耦合。
- 更方便替换具体实现。
- 更方便进行单元测试。
- 更适合复杂项目中的统一管理。
如下图所示:

IoC 和 DI 的区别
DI 全称是 Dependency Injection,中文通常翻译为"依赖注入"。
IoC 和 DI 描述的是同一件事的不同角度:
- IoC 强调的是控制权反转:对象创建和依赖管理的控制权,从程序代码转移到了容器。
- DI 强调的是实现方式:容器把对象需要的依赖注入进来。
也就是说,IoC 是思想,DI 是实现 IoC 的常见方式。

AOP
AOP 全称是 Aspect Oriented Programming,中文通常翻译为"面向切面编程"。它可以看作是 OOP 的一种补充。
OOP 的三大特征是封装、继承、多态。OOP 更适合描述纵向的对象关系,例如父类和子类、接口和实现类之间的关系。

出现的问题
OOP 能解决大部分代码复用问题,但有些场景并不适合只用继承来处理。
例如日志记录、事务控制、权限校验、性能监控等逻辑,可能会出现在很多业务方法的相同位置。如果直接写在每个方法中,就会造成大量重复代码。
如下图所示,多个方法中都出现了相似的附加逻辑,单纯依靠父类抽取并不合适:

横切逻辑代码

横切逻辑代码通常会带来两个问题:
- 横切代码在多个业务方法中重复出现。
- 横切逻辑和业务逻辑混在一起,代码臃肿,维护困难。
AOP 的思路是把这些横切逻辑单独抽取出来,再通过框架机制织入到目标业务方法中。

代码拆分本身并不难,真正关键的是:如何在不改变原有业务逻辑的情况下,把横切逻辑应用到目标方法中,并且达到和原来一样的执行效果。
这正是 AOP 要解决的问题。
AOP 在解决什么问题
AOP 主要解决的是横切逻辑复用和业务代码解耦问题。
它可以在不修改原有业务代码的前提下,对方法进行增强。例如:
- 方法执行前记录日志。
- 方法执行后统计耗时。
- 方法异常时统一处理。
- 方法执行时自动开启、提交或回滚事务。
- 方法调用前进行权限校验。
所以,AOP 的核心价值是:把通用的横切逻辑从业务代码中抽离出来,减少重复代码,让业务代码更加清晰。
作者:武子康的个人博客