我一直觉得Spring 是那种“用着用着就忘了它为什么存在”的框架。尤其是现在新手一上来就是 Spring Boot几个注解一标项目跑通了好像一切都理所当然。但一旦遇到 Bean 注入失败、循环依赖报错、事务悄悄失效这类问题就会立刻卡壳——因为你不清楚 Spring 到底在背后替你做了什么。这系列问题背后其实只有一个核心命题Spring 到底解决了什么问题想明白这个再看 IoC、AOP、三级缓存、自动装配全都能串起来面试题也不怕排坑也不慌。这篇博文我打算从“没有 Spring 的日子”讲起一步步拆解 Spring 的核心原理到后面加上我踩坑多年的实操心得希望能帮你把 Spring 从“会用”变成“心里有数”。1. 先回到没有 Spring 的年代它诞生的那批痛点1.1 对象创建与依赖管理从 new 对象讲起在 Spring 还没火起来的时候我们写 Java 后端大多是这种画风public class OrderService { private final OrderDao orderDao new OrderDao(); private final EmailService emailService new EmailService(); public void createOrder(Order order) { orderDao.save(order); emailService.sendConfirmEmail(order.getUserId()); } }这段代码有什么问题表面上看起来干净整洁实际上埋了三颗雷对象与对象之间是硬编码关系。OrderService直接new了OrderDao和EmailService意味着如果哪天EmailService的构造函数加了一个参数或者换成了SmsService你就要跑到OrderService里改代码甚至可能连锁影响十几个类。替换实现极其痛苦。测试时想用一个MockEmailService替换真实邮件服务你得改OrderService里的代码或者依靠手工注入这种方案在生产环境根本不可维护。对象的生命周期没人管理。谁来保证你创建的每个OrderService里只有一份OrderDao实例全靠程序员自觉。项目小的时候没事一旦模块多起来同一个 DAO 被 new 了十几遍资源开销翻倍排查起来还很难定位。有人会说用工厂模式不就行了比如写一个BeanFactory把创建对象的过程收拢到一个地方public class BeanFactory { public static OrderService getOrderService() { return new OrderService(new OrderDao(), new EmailService()); } }这确实解决了一部分硬编码问题但你还是要在工厂类里手动管理每一个对象的构造过程。一个类依赖另一个类工厂就会越写越长最后变成一份春天般的“意大利面条”。本质问题在于依赖关系的维护是手工的、显式的程序里到处都写着“谁来创建谁、谁依赖谁”。打个比方这就像一个人想搬家事无巨细都得自己联系货车、找工人、买纸箱、规划路线杂事占满了精力。而 Spring 做的事情就像把搬家这件事外包给了一家搬家公司你只需要告诉它“我要搬家、东西有这么多”剩下的打包、运输、摆放都由它来管。1.2 代码侵入与横切逻辑日志、事务为什么要到处写第二个痛点更隐蔽但也更折磨人。以前写业务方法经常会变成这样public void transfer(String fromAccount, String toAccount, BigDecimal amount) { // 手动开启事务 transactionManager.begin(); try { // 记录业务日志 logger.info(开始转账: {} - {}, 金额: {}, fromAccount, toAccount, amount); accountDao.decrease(fromAccount, amount); accountDao.increase(toAccount, amount); // 提交事务 transactionManager.commit(); logger.info(转账完成); } catch (Exception e) { // 回滚事务 transactionManager.rollback(); logger.error(转账失败, e); throw e; } }看这段代码真正跟业务相关的其实只有两行accountDao的操作剩下的全是事务控制、日志记录。如果项目里有几十个方法都要做类似的事情就意味着一模一样的事务逻辑被复制了几十份。更可怕的是如果某一天事务策略变了——比如某些方法要改成只读事务或者日志要加一个追踪ID——你就得跑到每一个方法里去改漏掉任何一个都是线上事故。这就是典型的横切逻辑问题。横切逻辑指那些“几乎每个业务方法都要做但又跟纯业务没有直接关系”的事情典型代表是事务、日志、权限校验、性能监控。用传统的面向对象思维很难优雅地处理横切逻辑因为它跟正常的类继承、接口实现完全不同——你不可能让每个业务类都继承一个“会打日志的基类”那样会把继承体系搅成一锅粥。正是这个痛点催生了 Spring 的 AOP面向切面编程能力也是后面会重点拆解的内容。1.3 配置与部署的割裂环境切换有多痛第三个痛点发生在项目从开发环境到测试环境、再到生产环境的过程中。在没有 Spring 生态的年代切换环境通常意味着改配置文件、重新打包。开发用本地数据库测试用测试库生产用生产库同一个数据源配置要在不同环境间反复修改漏改一处就得花半天排查。Spring 通过“容器 配置外部化”的方式统一解决了这个问题对象的创建规则、依赖关系、运行时参数全部集中在配置里环境切换只是选择不同 profile 或不同配置源的问题代码本身不需要改动。这在现在看来是标配但在那个年代属于革命性设计。理解了这些背景才能真正读懂后面 IoC 容器、AOP、自动装配这些设计的初衷。2. 核心答案第一半IoC 容器到底接管了什么2.1 控制反转的含义与本质先记住一句话IoC控制反转不是一种技术而是一种设计思想。它的核心是让“对象的创建和依赖关系的维护”不再是调用方的工作而是交给一个容器统一管理。看个简单对比不使用 IoC 时代码里的调用关系是这样表达的public class OrderController { private OrderService orderService new OrderService(); }使用 IoC 后代码变成public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } }注意区别OrderController不再自己创建OrderService而是通过构造函数“被动接收”。谁负责创建呢Spring 容器。这就是“控制权反转”——从“我自己 new”变成了“容器给我注入”。这种变化的价值体现在解耦。上层只关心接口/类本身不关心它的具体实现如何创建、如何组装。易于测试。测试时可以轻松传入 mock 对象。统一管理生命周期。单例 Bean 由容器统一创建和销毁避免了重复 new 带来的资源浪费。2.2 依赖注入的几种方式Spring 支持三种依赖注入方式在我接触过的项目里它们的出场率和踩坑概率差得还挺远的。构造函数注入推荐Bean 在创建时就固定了依赖所有属性不可变能有效避免循环依赖问题也能让开发者一眼看出这个 Bean 需要哪些依赖。Service public class OrderService { private final OrderDao orderDao; public OrderService(OrderDao orderDao) { this.orderDao orderDao; } }Setter 注入可用但慎用允许对象创建后再设置依赖灵活性高但会让依赖处于不完整状态。尤其容易引发“看似注入成功、实际是 null”的诡异问题。Service public class OrderService { private OrderDao orderDao; Autowired public void setOrderDao(OrderDao orderDao) { this.orderDao orderDao; } }字段注入最不推荐用Autowired直接打在字段上代码最短但隐患最大。它把依赖关系完全隐藏在类内部测试时要么靠 Spring 容器启动要么靠反射硬塞非常别扭。Service public class OrderService { Autowired private OrderDao orderDao; }我的建议很简单新代码一律用构造函数注入实在不行用 Setter字段注入只适合快速写 demo 时用。这不是洁癖是长期维护成本问题——你总不想几年后发现一个 Bean 的注入需要靠翻字段才能搞明白吧。注意Spring 官方在新版文档里也是明确推荐构造函数注入的这不是个人偏好问题。2.3 手写一个极简 IoC 容器理解 IoC 最好的方式不是只看 Spring 源码而是自己写一个迷你版容器。下面这段代码虽然简单到只能算玩具但把 IoC 的骨架完整呈现了出来。public class SimpleIocContainer { private final MapString, Object beanMap new ConcurrentHashMap(); // 注册 Bean 实例 public void registerBean(String name, Object bean) { beanMap.put(name, bean); } // 按名称获取 Bean public Object getBean(String name) { return beanMap.get(name); } // 按类型获取 Bean public T T getBean(ClassT type) { return beanMap.values().stream() .filter(type::isInstance) .map(type::cast) .findFirst() .orElseThrow(() - new RuntimeException(No bean of type: type.getName())); } }用法public class Demo { public static void main(String[] args) { SimpleIocContainer container new SimpleIocContainer(); OrderDao orderDao new OrderDao(); EmailService emailService new EmailService(); OrderService orderService new OrderService(orderDao, emailService); container.registerBean(orderService, orderService); OrderService service container.getBean(OrderService.class); service.createOrder(new Order()); } }这个容器没有自动扫描、没有注解支持甚至还要手工注册实例但它已经体现出了 IoC 的一切基础对象的创建集中在容器里调用方通过容器获取对象依赖关系由容器维护。Spring 的完整实现本质上就是对这套思想的工业级扩展注解驱动注册、自动类型装配、配置文件解析、生命周期回调、代理增强……写一遍就会发现Spring 的“黑魔法”并不神秘它不过是一套设计得非常完整的 IoC 实现。理解了这一点看 Spring 源码的路就顺了。2.4 Bean 生命周期与三级缓存循环依赖的谜底Spring 面试里被问得最多的除了 IoC 和 AOP 的基本概念就是“什么是三级缓存为什么需要三级缓存”我的理解框架是这样的Bean 创建过程大致是实例化new 出对象→ 属性填充设置依赖→ 初始化执行 init 方法 / 后置处理器。如果两个 Bean 互相依赖比如BeanA需要BeanBBeanB需要BeanA按顺序创建的思路就会死锁创建 A 时需要 B创建 B 时需要 A谁也没法完成。Spring 的解法是三级缓存// 第一级singletonObjects保存完全创建好的单例 Bean // 第二级earlySingletonObjects保存提前暴露的、尚未完成属性填充的 Bean // 第三级singletonFactories保存对象工厂用于生成早期的代理引用流程大致是这样创建BeanA时先“实例化”出原始对象把这个原始对象封装成工厂放入三级缓存再开始填属性。填属性时发现需要BeanB于是继续创建BeanB。BeanB创建过程中发现自己需要BeanA这时从三级缓存里拿到那个工厂提前“暴露”了一个BeanA的早期引用返回给BeanBBeanB的注入顺利完成。等BeanA自己也填完属性、走完初始化最终被放入一级缓存。需要说明的细节是如果 BeanA 被 AOP 代理了从三级缓存里暴露出来的“早期引用”必须是代理对象而不是原始对象否则后面增强逻辑就失效了。所以三级缓存里保存的不是直接对象而是对象工厂这个设计保证了代理创建时机不被破坏。我有一个很强烈的建议不要死记硬背三级缓存的名字而是要手绘一遍创建流程图画出 A、B 互相依赖时的每一步流程。画完一遍概念就真正属于你了。3. 核心答案第二半AOP 与动态代理如何解决横切逻辑难题3.1 AOP 怎么解决横切逻辑回到 1.2 节的那个痛点事务和日志代码无处不在地侵入业务方法。AOP 的解法是反直觉的——它把横切逻辑从业务代码里抽出来放到一个独立模块然后在运行时“织入”到目标方法上。从使用角度看它长这样Aspect Component public class LogAspect { Around(execution(* com.example.service.*.*(..))) public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable { long start System.currentTimeMillis(); Object result joinPoint.proceed(); long cost System.currentTimeMillis() - start; System.out.println(方法 joinPoint.getSignature().getName() 耗时 cost ms); return result; } }这样定义之后com.example.service包下的所有方法在执行时都会自动记录耗时业务代码里不会出现一行计时逻辑。这就是 AOP 的“无侵入增强”。3.2 动态代理的两种实现JDK 代理 vs CGLIBAOP 的底层机制是动态代理经典的切面增强本质上都是在创建代理对象在调用目标方法前后插入增强逻辑。JDK 动态代理只能代理接口。如果目标类实现了接口Spring 默认走 JDK 代理public class JdkProxyDemo { public static void main(String[] args) { UserService target new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), (proxyObj, method, methodArgs) - { System.out.println(before...); Object result method.invoke(target, methodArgs); System.out.println(after...); return result; }); proxy.getUser(1L); } }当目标类没有实现接口或 Spring 配置强制使用 CGLIB 时会通过生成目标类的子类来实现代理。CGLIB 通过继承产生一个子类重写父类方法从而实现对方法的拦截。这解释了一个实践中很重要的问题为什么有些类 AOP 增强不生效一个常见原因就是目标类或方法被final修饰CGLIB 无法为其生成子类自然无法代理。这里有一个我实际排过的坑某个Transactional方法所在的类被标记成final事务注解一直没有生效排查了很久。原因就是 CGLIB 无法改造 final 类事务增强根本没有织入进去。后面凡是遇到“注解写了但没效果”的问题我第一反应就是检查类和方法有没有被 final 修饰这个习惯帮我在排查路上省了大量的时间。3.3 AOP 如何撑起事务与安全权限理解了 AOP再回头看 Spring 两大核心组件就一目了然了。Transactional的本质是一个切面拦截器。Spring 在带有Transactional的方法上创建代理在方法执行前开启事务执行成功后提交异常时回滚。所以事务失效问题绝大多数可以归结为“切面没有生效”或“方法调用绕过了代理”。Spring Security的过滤器链路本质上也是基于 AOP 过滤器的思路在每个请求进入业务方法前做身份认证和授权拦截。权限校验逻辑之所以能跟业务代码完全隔离靠的正是 AOP 对横切逻辑的统一处理能力。可以这么说IoC 解决了“对象怎么来、怎么组装”的问题AOP 解决了“通用逻辑如何无侵入地复用”的问题。这两个能力加在一起构成了 Spring 的底座。4. Spring Boot把“解决问题”变成“开箱即用”4.1 自动配置原理从 Spring 到 Spring Boot 的跨越Spring Framework 之后Spring Boot 能火遍全球的原因是它把“配置成本”大幅降低。在没有 Boot 的年代搭建一个 Spring 项目涉及大量 XML 配置写 spring.xml、配数据源、配事务管理器、配 MVC 拦截器每样都要手工维护光是让一个 Hello World 跑起来就能耗掉新手半天时间。Spring Boot 的核心机制是自动配置它的原理可以总结为一句话Spring Boot 启动时会扫描META-INF/spring.factories或META-INF/spring/...AutoConfiguration.imports文件加载各种 AutoConfiguration 类然后根据当前项目的依赖和配置条件ConditionalOnClass等决定哪些配置生效。举个例子当你引入spring-boot-starter-web时ServletWebServerFactoryAutoConfiguration会自动配置内嵌 Tomcat当你引入spring-boot-starter-data-jpa时HibernateJpaAutoConfiguration会自动配置 JPA 相关组件。你不需要写任何配置文件因为 Boot 已经帮你把这些繁琐的默认值都填好了需要微调时再通过application.yml覆盖即可。这个设计的聪明之处在于“条件化”你有这个依赖我就帮你配置好你没有这个依赖我绝不干涉。用大白话说Spring Boot 就像一个会看菜下饭的厨师——你买来了哪些食材他就自动决定用哪些工具和做法。4.2 基于 Boot 的生态整合缓存、日志、微服务Spring Boot 不只是自动配置它还把整个 Java 后端生态整合成了“启动器”体系。一个个 starter 就相当于一个“功能插头”插上就能用Spring Boot Redis引入spring-boot-starter-data-redis配置连接信息就能直接用RedisTemplate。Spring Boot Cache引入spring-boot-starter-cache配合 Caffeine 等本地缓存几分钟就能给接口加上缓存能力。Spring Boot WebSocket引入 WebSocket 相关依赖通过配置类注册端点即可实现实时消息推送。Spring Boot MinIO引入 MinIO SDK配置 endpoint 和密钥就能对接对象存储服务。这些组合在今天的开发者眼里是“理所当然”的但要知道这背后每一套都需要解决配置加载、依赖管理、连接池、异常处理等一堆细节。Spring Boot 把这些都标准化了才让“拿 Spring 写项目”变成一件低成本的事情。4.3 从 Spring 到 Spring Cloud 与微服务体系随着业务规模变大单一应用会慢慢拆分为多个服务。Spring Cloud 就是在 Spring Boot 基础之上解决分布式场景问题的全家桶服务注册发现Nacos、Eureka、配置中心Nacos Config、负载均衡LoadBalancer、服务调用OpenFeign、链路追踪Micrometer Tracing、网关Spring Cloud Gateway。我见过不少团队是从单体 Spring Boot 项目逐步演进到微服务架构的。最初可能只是把用户模块拆出去后来订单模块也拆了然后发现服务之间调用、配置管理、服务发现这些问题单靠 Spring Boot 已经不够用了于是引入 Spring Cloud 体系。注意一个关键点Spring Cloud 依赖 Spring Boot 的自动配置和 Bean 管理机制但没有 IoC/AOP 这套底座微服务组件根本没法如此默契地协同。从热搜词里也能看到像“Python 应用融入 Spring Cloud Alibaba 微服务体系”这类话题很热。这恰好说明 Spring 已经不只是 Java 领域的框架而是演变成一个开放的技术生态标准。理解 Spring 核心原理等于掌握了理解这套生态的万能钥匙。5. 学习与排查的实操心法5.1 常见问题速查表遇到这些坑怎么处理下面这些是我在真实项目中反复遇过的 Spring 经典问题整理成一个速查表建议收藏现象根本原因解决方案循环依赖报错BeanCurrentlyInCreationException构造函数注入导致的循环依赖无法用三级缓存解决改为 Setter/字段注入不推荐或重新设计依赖关系Autowired注入为 null对象由 new 手动创建不由 Spring 管理需要注入的对象也交给 Spring 管理或用Configurable配合 AspectJTransactional方法不生效事务方法被同类内部调用绕过了代理把需要事务的方法拆分到其他 Bean或自注入代理多个实现类注入时NoUniqueBeanDefinitionException接口有多个实现Spring 不知道该选哪个使用Qualifier指定名称或用Primary标注首选Bean 属性未注入成功注解位置错误或没有开启组件扫描检查ComponentScan扫描包路径确保注解在字段或 Setter 上AOP 增强不生效类或方法被 final 修饰CGLIB 无法代理去掉 final 修饰或改用组合方式实现配置文件中中文乱码properties 文件默认使用 ISO-8859-1不是 UTF-8改用 yaml 文件或使用 Unicode 转义这里多说一句“同类内部调用”的问题它是事务失效的最高频原因。看这个例子Service public class OrderService { Transactional public void createOrder() { // 业务逻辑 } public void createWithCheck() { // 做一些校验 this.createOrder(); // 这里的事务注解不会生效 } }原因是 Spring 的事务增强靠的是代理对象this.createOrder()调用的是原始对象的方法代理拦截器根本没进入事务自然就没了。解决方式有几种把createOrder拆到另一个 Bean 里调用或者注入自身代理或者用TransactionTemplate编程式事务。这些方案里最推荐的是拆类因为语义清晰也不依赖 Spring 内部机制。5.2 看源码的正确姿势不少朋友看 Spring 源码是直接去看AbstractApplicationContext.refresh()然后一头扎进几百个方法里出不来。以我的个人经验建议按顺序来先跑通一个最小的 Spring 项目对 IoC 容器有感性认识。手写一遍极简 IoC 容器体会核心思想。重点看DefaultListableBeanFactory它是 IoC 容器的心脏看它与 BeanDefinition 的交互方式。再看AbstractAutowireCapableBeanFactory.createBean()围绕 Bean 的实例化和属性填充看。最后才看refresh()理解容器的整体启动流程。这个顺序背后是有逻辑的从简到繁、从点到面。一开始就扎进refresh()会被庞大的调用树吓退但如果先理解了 BeanFactory 的核心逻辑再看启动流程时会发现所有步骤都是“在 factory 基础之上做扩展”理解成本会大幅下降。我还强烈建议多画图。Spring 源码的调用链往往跨越十几个类仅凭记忆很难整理清楚。画一张 Bean 创建时序图、一张循环依赖解决流程图、一张自动配置加载流程图这三个图搞明白Spring 的主干原理你已经赢了大部分开发者。5.3 现在开始学习 Spring 从哪里入手对完全零基础的人来说我的建议是不要一上来就扎到源码里。按下面这条路径走会比较顺畅第一阶段会用。拿 Spring Boot 写一个简单的 Web 接口感受自动配置带来的便利理解 Controller、Service、Dao 分层。第二阶段懂原理。阅读本文前面几个章节理解 IoC、AOP、Bean 生命周期的概念配合官方文档和你自己的示例代码去验证。第三阶段懂源码。按 5.2 节推荐的顺序读源码或者跟着手写 Spring 的教程敲一遍。第四阶段懂生态。逐步接触 Spring Security、Spring Cloud、Spring AI 等相关组件你会发现它们的底层机制全都是 IoC AOP 的延伸。关于 Spring AI我也多说一句。现在 AI 应用开发越来越热Spring AI 通过统一的接口封装大模型调用、RAG检索增强生成能力本质上也是在做“把复杂技术标准化”的事情。这个思路跟当年 Spring 封装 JDBC 是一模一样的。理解 Spring 的核心设计原则再看这些新组件、新模块会有一种“万变不离其宗”的轻松感。6. 写在最后的实操体会学了这么多年 Spring踩了无数坑之后我最大的体会是Spring 解决的不是某个具体功能问题而是软件开发中“管理和组装”的通用问题。对象怎么创建管理横切逻辑怎么复用配置怎么外部化这些问题是任何后端项目都要面对的而 Spring 给出了一个经过大规模验证的标准答案。所以我建议所有想深入后端开发的同行至少在工作的第一年里把本文涉及的这些概念亲手验证一遍。不要只满足于“注解能用就行”而是要让“为什么这么设计”成为你学习的主线。等你亲手写过一个极简 IoC 容器、手动模拟过一次循环依赖、用动态代理写过一遍 AOP你会发现自己看 Spring 的视野变得完全不同——它不再是黑盒而是一位熟悉的伙伴。最后再分享一个小技巧遇到 Spring 的疑难杂症不要只盯着异常信息看先把“Spring 框架自身是怎么设计这一环节的”捋顺再回到异常信息你会发现线索都在眼前。原理是一条线把散落的坑串在一起这就是学习框架最好的方法。