很多人在Spring官网停留的时间不会超过五分钟理由都一样项目太多了。Spring Framework、Spring Boot、Spring Cloud、Spring Data、Spring Security光看导航栏就头晕。但说句实在话Spring的内核非常小——就是控制反转容器加AOP代理这两个东西理解透了整个Spring架构的地图就打开了。这篇文章要做的就是把整幅Spring架构图展开从底层容器到微服务层一层层拆开给你看最后给一条我这些年带新手总结出的系统化学习路线。不说废话全部是可以直接落地的东西。适合正在学Spring、被各种概念绕晕的初学者也适合想系统梳理一遍Spring体系的开发者。1. 一张图看懂Spring架构五个模块与三层容器先说结论Spring框架本身不是一坨铁板而是分成了多个独立但又互相协作的模块。理解Spring架构只需要记住五个模块加三层容器。┌─────────────────────────────────────────────────────┐ │ 你的业务代码Controller/Service/DAO │ ├─────────────────────────────────────────────────────┤ │ Web模块 │ │ Spring MVC / WebFlux / WebSocket │ ├─────────────────────────────────────────────────────┤ │ 数据访问模块 │ │ JDBC / ORM / Transaction / JMS │ ├─────────────────────────────────────────────────────┤ │ AOP与切面 │ │ Spring AOP / AspectJ │ ├─────────────────────────────────────────────────────┤ │ 核心容器 │ │ Beans / Core / Context / SpEL │ └─────────────────────────────────────────────────────┘1.1 核心容器Spring的发动机核心容器是整个Spring的底座通常被缩写为IoC Container。它由四个子模块组成Core、Beans、Context、SpEL。Core提供框架的基础工具类Beans负责Bean的定义、创建和管理Context是容器的运行时环境SpEL是Spring自带的表达式语言可以在配置里做动态取值和逻辑处理。初学者最容易忽略的一点是Spring的核心容器根本不需要Web环境就能运行。你可以写一个最简单的main方法加载ClassPathXmlApplicationContext或者用AnnotationConfigApplicationContext就能让Spring容器跑起来。这正是Spring架构优雅的地方——Web层只是挂在容器之上的一个模块不是容器存在的必要条件。很多新手一上来就写Spring Boot项目结果出了问题根本分不清是容器的问题还是Web层的问题就是因为脑子里缺少这层分离的概念。我把容器比作一家餐厅的后厨。你的业务代码是点菜的顾客只需要告诉服务员想吃什么声明依赖后厨会帮你把菜做好餐具摆好端到你面前。后厨就是Spring容器做菜的过程你完全不需要关心。1.2 其他四个模块各管一摊AOP模块负责切面编程把日志、权限校验、事务这类横切逻辑从业务代码里抽离出来。数据访问模块管理JDBC连接、ORM框架集成和事务控制。Web模块提供MVC框架和WebFlux响应式编程支持。Test模块提供单元测试和集成测试的便利工具。这里要特别说明模块之间不是平等的依赖关系。核心容器在最底层AOP建立在核心容器之上数据访问和Web模块都依赖核心容器与AOP模块。理解这个依赖关系很重要因为Spring官方文档里每一个模块的介绍都默认你已经知道IoC是什么。这也是为什么很多人直接看Spring Boot文档会懵——Spring Boot虽然是Spring家族的一员但它解决的是“配置繁琐”的问题而不是容器的问题。我把这五个模块整理成一个表格方便构建记忆坐标模块分组核心功能典型场景依赖底层Core ContainerBean管理、依赖注入、上下文环境IoC容器启动、Bean装配无AOP切面逻辑、代理机制日志切面、权限校验、事务通知Core ContainerData Access数据访问、事务抽象JDBC操作、MyBatis/JPA集成、声明式事务Core AOPWebMVC、响应式编程Controller接口、过滤器、WebSocketCoreTest测试支持单元测试、MockMvc集成测试Core1.3 Spring Boot和Spring Cloud不算Spring Framework这是新手最容易混淆的概念。Spring Boot不是Spring Framework的模块而是建立在Spring Framework之上的一套自动配置封装。它通过starter依赖统一管理第三方库版本通过自动配置类把原本需要写大量XML或JavaConfig的工作隐藏起来。同理Spring Cloud又是一层封装负责分布式环境下的服务发现、配置管理、负载均衡、熔断限流。换句话说Spring体系是三层结构最底层是Spring Framework解决对象管理问题中间是Spring Boot解决开发效率问题顶层是Spring Cloud解决分布式架构问题。学习的时候一定要按这个顺序走跳级必踩坑。2. 核心机制拆开讲IoC、AOP、Bean生命周期与三级缓存如果只让我挑三个Spring最核心的知识点那就是IoC、AOP和Bean生命周期。这三个点不只是面试必问更是理解Spring架构图的钥匙。下面逐个拆开讲原理直接给到位。2.1 控制反转不是在搞魔法而是换个地方new对象控制反转Inversion of Control本质上是把对象的创建和依赖关系的管理从调用者手里转移给容器。传统写法里你在Service里new一个Dao这个Service就和具体Dao实现类耦合死了。用Spring后你只管声明“我需要一个Dao”容器会创建一个实例并注入进来。依赖注入有三种姿势字段注入、Setter注入、构造器注入。我的建议是优先使用构造器注入原因很实际构造器注入能保证依赖在对象创建时就已经完备不会出现字段注入那种“对象已经建好了但依赖还是空的”的隐患而且更容易写单元测试。字段注入写起来最省事但Spring团队在官方文档里已经明确不推荐了原因在于它绕过封装也容易导致测试时依赖不明确。容器管理Bean默认是单例模式也就是整个容器里同一个Bean只有一个实例。大部分场景下单例是合适的选择但如果你的Bean里存了可变状态或者你需要每次获取都拿到全新对象就把Scope(prototype)加上。这是初学者比较容易忽略的一个细节。2.2 AOP的底层是代理代理的底层又是什么AOP全称Aspect Oriented Programming面向切面编程。核心思想是把横跨多个业务模块的逻辑日志、权限、事务、性能统计提取出来做成切面业务代码里不再关心这些逻辑。Spring AOP的底层机制是动态代理。如果目标类实现了接口Spring使用JDK动态代理如果目标类没有实现接口Spring使用CGLIB生成子类代理。JDK动态代理基于InvocationHandler接口运行时生成一个实现了相同接口的代理对象CGLIB则是通过字节码技术生成目标类的子类。两种代理方式各有优劣JDK代理只能代理接口方法CGLIB可以代理所有非final类和方法。理解代理机制对排查问题很有帮助。比如你有事务不生效的问题十有八九和代理有关系——目标方法不是通过代理对象调用的而是通过this直接调用代理逻辑自然就不会执行。这类问题下面第五节专门讲。2.3 Bean生命周期从诞生到销毁的全过程Bean生命周期是理解Spring容器管理的核心。完整的生命周期可以分成几个阶段实例化容器通过反射创建Bean实例属性填充把依赖注入进去Aware接口回调比如BeanNameAware、ApplicationContextAwareBeanPostProcessor前置处理初始化方法PostConstruct、afterPropertiesSet、init-methodBeanPostProcessor后置处理使用Bean容器关闭时销毁PreDestroy、destroy-method这个过程中最值得关注的是BeanPostProcessor它是Spring扩展能力的核心入口。AOP的实现原理其实就是在BeanPostProcessor的后置阶段判断这个Bean是否需要生成代理对象如果需要就把目标Bean包装成代理返回。2.4 三级缓存解决循环依赖为什么要三级循环依赖问题在面试里出现频率极高。场景很简单A依赖BB又依赖A两个Bean创建时互相等待。Spring通过三级缓存来应对这个问题三个缓存分别是一级缓存singletonObjects存放完全初始化好的单例Bean二级缓存earlySingletonObjects存放提前曝光的早期Bean引用属性还没填充三级缓存singletonFactories存放Bean的ObjectFactory用于生成早期引用的工厂整个流程是创建A时A发现自己需要B于是先去创建BB发现自己需要A这时B从三级缓存拿到A的早期引用这个引用可以注入给BB创建完成后A再从缓存里拿到完整的B完成注入。三级缓存里存的是一个工厂方法可以在适当时候生成代理对象这是二级缓存做不到的。如果只需要解决循环依赖二级缓存就够了但Spring还要保证AOP代理的时机正确所以必须用三级。需要注意的是三级缓存只能解决字段注入和Setter注入产生的循环依赖构造器注入的循环依赖Spring无法处理因为构造器在执行前还没有对象可以提前暴露。遇到这种情况最常用的解法是使用Lazy注解或者在设计依赖关系时避免互相引用这也是我在真实项目里的处理原则能不改代码就尽量调整依赖结构。2.5 事务管理Transactional背后的魔法Spring声明式事务用起来很简单一个Transactional注解搞定。原理其实不复杂Spring AOP为标注了事务注解的方法生成代理在方法执行前开启事务方法正常结束就提交抛出异常就回滚。但坑都在细节里。事务失效的场景我整理过出现频率最高的有三个一是方法被private修饰代理无法拦截二是在同一个类内部通过this调用带事务注解的方法绕过代理三是自己catch了异常没有往外抛事务管理器感知不到异常自然不回滚。传播行为也值得花时间搞清楚。默认的REQUIRED表示如果当前已有事务就加入没有就新建。REQUIRES_NEW则是无论如何都开启新事务适合需要独立提交的日志记录或审计逻辑。写接口时不要盲目给所有方法都加REQUIRES_NEW事务开销和连接池占用都会增加。3. 从Spring Framework到Spring Boot再到Spring Cloud的演进Spring架构的体系还在不断变大。理论上说只学Spring Framework也够写单体应用但现实里的项目几乎都从Spring Boot起步团队大一点就会上微服务。这部分帮你理清楚这几层之间的关系。3.1 Spring Boot到底帮你省了什么Spring Boot最大的贡献是解决了配置地狱。传统Spring项目里你可能要写多个XML文件配置数据源、配置事务管理器、配置视图解析器、配置组件扫描。Spring Boot通过自动配置机制把这些固定模式的配置全部接管了。自动配置的入口是SpringBootApplication它由三个注解合成SpringBootConfiguration表示这是一个配置类EnableAutoConfiguration开启自动配置ComponentScan启动组件扫描。其中EnableAutoConfiguration通过AutoConfigurationImportSelector读取META-INF目录下的AutoConfiguration.imports文件按条件加载需要的自动配置类。条件装配是自动配置能智能生效的关键。Spring Boot提供了一系列条件注解最常用的是ConditionalOnClass和ConditionalOnMissingBean。原理是你引入了一个starter依赖classpath里有了对应的类自动配置才会生效如果自己手动显式声明了Bean自动配置的Bean会通过ConditionalOnMissingBean退让不覆盖用户的配置。yml配置文件也是Spring Boot的亮点。以集成WebSocket为例你可以在yml里指定websocket相关参数配合配置类完成端点注册。外部化配置有优先级命令行参数高于application.ymlapplication.yml高于系统环境变量。我在实际运维时排查过项目里明明改了配置文件却不生效的问题最后发现是因为打包时漏了把新配置打进去或者启动脚本里带了旧参数覆盖了文件配置。3.2 Spring Cloud是分布式生态的解决方案集当服务拆分成多个模块后会遇到一系列新问题服务之间如何找到对方配置如何统一管理流量异常时如何限制网关怎么统一鉴权。Spring Cloud就是围绕这些分布式痛点形成的解决方案集合。典型组件包括注册中心Nacos或Eureka负责服务注册与发现配置中心负责统一管理配置并支持动态刷新Gateway负责统一入口和路由转发OpenFeign负责服务间调用Sentinel或Hystrix负责熔断降级Sleuth或Micrometer负责链路追踪。我自己在实际微服务项目里最推荐Nacos因为它把注册中心和配置中心合二为一部署上能少套件一个问题域。学习的时候建议先跑通一个最小集群一个注册中心、两个服务、一个网关把调用链路跑通再去逐个深入其他组件。一上来就搭几十个微服务的架构是不可取的学习阶段只需要理解核心链路的交互逻辑。我在部署基于Spring Cloud Alibaba的微服务项目时处理过一个比较典型的场景多个服务共享一套配置里面包含数据库连接信息但各服务所在环境硬件条件不同。最后通过Nacos的不同namespace区分环境结合组概念区分服务把共用配置抽到共享组里各服务自己的配置保留在本组。这个设计直接减少了后续发版时人工改配置的量。3.3 Spring AI架构图里正在增长的新版图近两年Spring社区新冒出来的热点是Spring AI热词里大量出现Spring AI、Spring AI RAG、NL2SQL等关键词。Spring AI定位是AI应用开发的抽象层统一对接不同大语言模型厂商的API把Prompt模板化、上下文记忆管理、RAG检索增强这些能力做成Spring风格的工具。我的判断是Spring AI会让Java在人工智能应用开发里的存在感大幅提升因为它提供了和Spring生态一致的编程模型。但初学者现阶段重点关注还是IoC、AOP、事务这三板斧。AI相关的内容等基础扎实了再去碰收益会高很多。JDK的核心类库反射和动态代理是Spring框架的底层依赖泛型是写框架级代码的基础。这个阶段能和SSM框架融合练习做一个带增删改查的小系统。Transactional、事务传播行为、事务失效场景实测。这个项目的关键点在于不要只满足于跑通功能要刻意使用事物。单元测试怎么在Spring环境中使用MockMvc测试接口。除此之外我建议做一件事手写简化版Spring。不需要实现全部功能只需要实现一个简易的IoC容器扫描包路径、识别注解、完成依赖注入、维护单例池。把循环依赖的判断逻辑也加上。这一步做完你对Spring架构的认知会和只看文档完全不一样。第四阶段Spring Boot12周重点是自动配置原理、starter机制、yml外部化配置、Actuator监控、集成WebSocket等场景。第五阶段Spring Cloud微服务23周重点是服务注册发现、OpenFeign远程调用、Gateway路由转发、Nacos配置中心、Sentinel熔断限流。项目时的学习侧重点要动态切换。像餐饮SaaS这类业务里常见的AI集成需求或者NL2SQL这种自然语言查数据库的场景等理解了Spring AI的基本调用方式后再结合RAG做知识库问答应用这个路径比一上来就死磕源码更有效。4.2 学习路线的三个常见误区第一个误区是跳过Spring Framework直接学Spring Boot。现在网上Spring Boot教程铺天盖地傻瓜式上手让不少人觉得不需要学Framework。问题是一旦开发的复杂度和协作规模变高排查起来非常困难。我在排查线上问题时见过不下十次这样的场景一个Bean重复定义了两个类的名称相同导致注入报错同事面对报错信息完全没头绪问题就出在他不知道Spring容器是如何扫描和装配Bean的。第二个误区是只敲代码不思考原理。写代码和懂原理并不冲突你的目标不是背面试题而是积累判断力。为什么构造器注入比字段注入更值得用为什么事务注解自调用会失效这些问题代码不会直接报错但不搞清楚会让架构设计充满隐患。第三个误区是啃源码之前没有整体框架。框架源码不是线性阅读的东西一旦在某个类的调用链里迷路了就全盘崩溃。我建议阅读源码前先画出调用流程比如请求进入Spring MVC后大致经过DispatcherServlet、HandlerMapping、HandlerAdapter、ViewResolver这些环节再针对某个环节深入。有地图后再推进源码阅读会顺畅得多。5. 一个阶段学习路线的配套代码设计针对初学者我额外设计了一套配套代码结构按照学习阶段渐进递增复杂度。第四阶段前使用Maven聚合工程在Spring Framework容器中运行。这个设计的好处是能直观看到容器在无Web环境下的运行方式。第一阶段用main方法手写ReflectDemo体会反射和工厂模式如何解耦。第二阶段直接使用Spring Framework展示IoC与AOP。第三阶段使用SSM组合构建Web应用启动Tomcat跑通全流程。第四阶段迁移到Spring Boot把原有的XML配置替换成starter依赖和yml配置。每步配套一条主线和若干分支主线保证学习节奏分支用于拓展视野。这样跑下来你会很自然地发现Spring Boot只是个壳真正的Spring骨架在第一和第二阶段就已经建好了。6. Spring初学者的踩坑实录问题与排查速查表这部分内容完全来自我自己的实操积累。没有任何教科书会把这些细节写全但每一个都卡过我非常多的时间。6.1 循环依赖报错BeanCurrentlyInCreationException循环依赖报错很常见。如果使用构造器注入出现循环引用Spring容器启动时会抛出BeanCurrentlyInCreationException。解决办法优先改设计把依赖关系拆开或者使用字段注入Setter注入或者给其中一个依赖加Lazy。我在代码评审时一般不接受循环依赖的解决方案因为循环依赖本身就是设计信号说明职责划分不够清晰。6.2 Bean重复定义同一类型两个候选Spring容器扫描到两个相同类型的候选Bean时会自动按属性名匹配找不到就会报NoUniqueBeanDefinitionException。解决办法是使用Primary指定首选Bean或者使用Qualifier指定名称。还有一种情况多人协作时同一个类名被复制到不同的包路径下容器扫描到两个同名的类这时建议用ComponentScan的excludeFilter排除多余路径从源头清理掉。6.3 Autowired注入对象为null常见原因很多多数是对象本身没有被Spring管理。确认方法很简单看你注入的类有没有Component、Service、Repository等注解有没有被Spring的扫描路径覆盖。Spring Boot的默认扫描范围是启动类所在包及其子包把Controller放在启动类之外的包目录里就扫不到。还有一种情况是new出来的对象内部做注入Spring管理的Bean里的注入才有效手动new出来的对象容器不会管。6.4 事务不生效的几种具体场景Spring事务不生效的排查顺序我建议按这个来先看方法修饰符是不是public再看方法是不是从内部用this调用再看异常有没有被catch吞掉再看类是否被Spring代理。还有一种隐藏场景多线程调用事务方法事务不会生效因为事务机制和线程绑定在一起每个线程各自管理连接。6.5 yml配置不生效的排查套路项目启动后发现配置没生效查一下这个顺序配置文件放的位置是否正确默认在resource目录下配置文件名称是application还是bootstrap前缀是否有环境变量或命令行参数覆盖配置类字段名和yml中绑定是否一致。Spring Boot配置绑定在默认情况下是宽松匹配的like firstName可以匹配first-name如果字段名完全对不上大概率是你代码里写的和配置文件里写的有拼写差异。6.6 Spring常见问题速查表现象可能原因解决思路启动时BeanCurrentlyInCreationException构造器循环依赖调整依赖结构 / 使用Lazy延迟代理NoUniqueBeanDefinitionException同类型多个候选Primary指定优先候选 / Qualifier指定名称Autowired字段为null对象未被容器管理检查扫描路径 / 增加Component注解事务方法无回滚异常被吞、非public方法、自调用抛出异常 / 改为public / 获取代理对象后调用配置文件不生效名字、位置、覆盖、绑定字段名有误按五步顺序排查配置加载链路WebSocket连接建立失败端点映射不对、拦截器报错、握手超时先看后端日志再分析前端握手请求确认路径和协议升级这张表可以打印出来贴在工位上排查问题时对照着看多数情况能省半小时。7. 写在最后我的几个实际体会带过几个转行的朋友之后我最大的体会是学Spring最忌讳的就是急着跑Spring Boot项目。Boot的自动配置把很多细节藏了起来用起来方便但一旦报错就无处下手。现在的教学视频和官方文档都在强调快速上手但快速上手和真正理解是一对长期存在矛盾的目标。我自己的处理方法是把这个矛盾拆开第一阶段故意不用Spring Boot用原生Spring写一个控制台项目手动声明Bean、配置AOP切面、手动管理事务。等这套流程摸清楚了再进入Spring Boot你再看那些自动配置会特别亲切因为你已经知道它在替你做什么了。另外有一个小技巧我在带新手的时候经常用学任何Spring知识点先想一个问题——“如果不用Spring这时我应该写多少代码”。想清楚对比后你才会真正明白Spring每一次抽象的价值所在。这套思维方式比背任何代码都扎实。这张Spring架构图现在你可以试着闭眼自己画一遍。五个模块从下往上叠容器在最底层Boot在框架之上打辅助Cloud在最外层管全局。把这条主线记住后面学什么都不会迷路。