1. 从new对象困局到控制反转这套机制到底解决了什么我先说一个特别真实的场景。前两年接手一个老项目订单模块里创建订单的代码从上到下一串newnew UserService()、new ProductService()、new InventoryService()、new CouponService()然后这几个Service内部又各自new了一堆别的类整个调用链路就像串葫芦改一个底层的数据库访问类牵连七八个上层文件跟着改。最痛苦的是单元测试——你想要单独测一个下单逻辑结果它背后new出来的依赖全都要真实跑起来没数据库就等着报错吧。后来团队花了两个迭代把所有对象创建全部改成通过Spring容器来管理代码清爽了不止一个档次测试也好写了。这就是依赖注入Dependency Injection这套机制的存在意义它把创建对象并建立对象之间协作关系这件事从业务代码里剥离出来统一交给Spring容器处理。你不再需要自己决定UserService依赖的UserMapper是哪个具体实现只需要声明我需要一个UserMapper容器会在合适的时机、以合适的方式把现成的实例提供给你。这个概念听起来简单但真正理解它对很多开发来说有一个坎。我见过不少工作两三年的同事能熟练写出Autowired但你要问他控制反转的控制到底反转到谁手里了他会愣住。其实答案是控制权从你的业务代码反转到容器了。以前是代码主动new现在是容器主动给你的代码从掌控方变成了被供给方这个视角转换是理解整篇文章的地基。更关键的是这套机制带来的不只是不用new了这一层好处它还把对象生命周期管理、作用域控制、延迟初始化、条件装配这些能力统统纳入了容器统一管理。你在业务代码里永远不需要关心这个Bean是单例还是每次新建它什么时候销毁销毁前要不要做清理这些全部由容器接管。下文我会从注入方式的选型、容器的底层工作机制、经典的三级缓存再到各种真实场景下的坑一层层拆开讲。2. 三种注入方式的前世今生我为什么最终倒向构造器注入2.1 字段注入写起来最爽坑起来最狠先说说最流行的字段注入Service public class OrderService { Autowired private OrderMapper orderMapper; Autowired private InventoryService inventoryService; Autowired private CouponService couponService; // 业务方法省略... }这种方式写起来确实舒服两行注解搞定不写构造函数代码看着也简洁。新人上手特别快很多项目组默认都是这么写的。但它的麻烦在第几个不可见的角落第一个问题是职责边界被藏掉了。类依赖的东西越多构造器参数越多一眼就能看出这个类有多重、承担了多少职责。字段注入则把这些信息全都抹平了——你看代码时根本看不出OrderService到底需要哪些依赖才能工作全部浇灌在字段上。等到哪天要重构想给这个类增加一个依赖你加了字段Spring也注入成功了但测试环境和线上环境可能表现不一致因为测试时如果用new来创建对象这个字段就是null你根本不知道要传什么进去。第二个问题是和不可变对象的设计哲学冲突。用final修饰的字段在字段注入里完全用不了因为字段注入是先创建对象、后填充属性这意味着对象在构造完成后还可以被修改这不是Spring特有的问题而是设计层面的妥协。第三个问题在实际项目里最扎心依赖关系在编译期是隐性的。IDE和编译器无法帮你检查——你漏了某个依赖编译照样通过只有容器启动时才会报NullPointerException或BeanCreationException把问题推迟到了运行期。我记得有一段时间这个话题特别火热Spring官方文档也明确推荐用构造器注入。道理很简单构造器签名就是依赖清单IDE有提示编译器有检查测试时直接new OrderService(mockMapper, mockInventory)就把依赖传进去了不用费尽心思搞反射。2.2 Setter注入兼容老代码的过渡方案Service public class OrderService { private OrderMapper orderMapper; Autowired public void setOrderMapper(OrderMapper orderMapper) { this.orderMapper orderMapper; } }Setter注入曾经是Spring早期版本的主流玩法XML配置时代尤其常见。它的好处是Bean可以先通过无参构造器创建再通过Setter把依赖塞进去这样即使依赖里有循环引用也不至于直接炸掉同时Setter方法本身还是普通的Java方法可以在运行时被重新调用给可选依赖提供了动态性。但它的问题同样明显调用顺序不可控。如果A类实例化时依赖BB实例化时又依赖A——Setter注入能绕开一部分问题但绕开的方式是把依赖不可变的保障也绕开了。字段不声明为final对象一直处于可被修改的状态这对并发场景和缓存场景存在隐患。我的看法是如果你维护的是老项目里面已经有一堆Setter注入的代码不值得全部推翻重写它是可以正常运转的但新写的代码除非有特殊需求不要再用Setter注入作为默认方案。它和字段注入相比唯一实质优势是支持容器运行期动态改依赖但我在实际项目里很少遇到这种需求。2.3 构造器注入唯一让我觉得手里的代码是稳的的方式Service public class OrderService { private final OrderMapper orderMapper; private final InventoryService inventoryService; private final CouponService couponService; public OrderService(OrderMapper orderMapper, InventoryService inventoryService, CouponService couponService) { this.orderMapper orderMapper; this.inventoryService inventoryService; this.couponService couponService; } }这段代码的好处一句话总结依赖就是构造参数缺了就别想创建。你想测试直接new OrderService(mock1, mock2, mock3)一行搞定不需要Spring容器参与。字段不可变final创建完就是定型了。还有一个很多人没注意到的隐形收益编译期就能发现多依赖或漏依赖。如果OrderService不依赖CouponService了你删掉字段和构造参数编译照样过但如果某个依赖漏加IDE会直接报红你在写代码时就发现了不需要启动整个Spring容器去验证。Spring 4.3之后多参数构造器上可以只标注一个Autowired甚至如果整个类只有一个构造器连Autowired都可以省略Spring会自动选择这个构造器来进行注入。所以在Spring Boot项目里代码可以精简成上面那样连注解都不用写。2.4 三种方式选型对比一张表讲透| 维度 | 字段注入 | Setter注入 | 构造器注入 |------|---------|-----------|------------|------| | 代码简洁度 | 最简洁 | 中等 | 略冗长 | 依赖可见性 | 隐藏在所有字段里 | 通过Setter入口可见 | 构造器签名即依赖清单 | 不可变性 | 字段可变无法用final | 字段可变 | 字段可final | 编译期检查 | 无漏依赖运行期才知道 | 无 | 有编译即暴露问题 | 单元测试友好度 | 低需要反射或容器 | 中等 | 最高直接new | 循环依赖处理 | 可绕过属性提前暴露 | 可绕过 | 无法绕过直接抛错 | 官方推荐 | 不推荐 | 早期推荐 | 强烈推荐表格不是万能的实际项目中你还会遇到各种特殊场景。比如有些场景确实适合字段注入——比如工具类里注入RestTemplate这种没有它就没法干活但你永远不需要在测试里替换它的固定依赖。这不是教条原则是优先构造器注入特殊情况大胆用字段注入但心里要清楚代价。3. 容器内部的工作流水线Bean的创建之旅与背后机制很多人用了一辈子Spring对容器的印象就是反正它能给我一个对象。但真正遇到问题——比如为什么我的Bean是null为什么同一个类会有两个实例为什么属性没被填充——就抓瞎了。搞清楚Bean在容器里到底经过什么环节很多病都能提前预防。3.1 从配置信息到BeanDefinition第一步是知道你有哪些Bean容器启动时第一件大事是扫描配置信息注解、XML、JavaConfig把每个可以被Spring管理的类解析成一份BeanDefinition。你可以把它理解成一张生产图纸——图纸上写着这个Bean的类名是什么、是单例还是原型、初始化之前要不要执行某种回调、字段上有没有Autowired需要额外处理、构造函数是什么样。这一步很关键因为Spring此时还没有创建任何对象它只是把关于对象的元信息准备好了。类似开餐厅前你先准备菜单客人还没来菜也还没炒。很多初学者容易把容器知道这个Bean存在和容器已经创建了这个Bean混为一谈。诊断问题的时候这个区分非常重要——比如你配置了Lazy延迟加载那可能到第一次使用时容器才真正创建实例如果业务代码里提前去getBean拿到的是Spring的代理对象不是真实对象。3.2 实例化 vs 初始化中间差了十万八千里很多开发以为Spring创建Bean就是new一个出来给你。远不止。Bean的创建完整流程大致经过这几个环节容器根据BeanDefinition通过反射调用构造器创建一个原始实例此时所有属性还是默认值依赖还没注入。如果这个Bean声明了Aware相关接口比如BeanNameAware、ApplicationContextAwareSpring会把容器自身的信息传递进去。如果Bean配置了BeanPostProcessor前置处理器执行相关的预处理方法。填充属性——这个环节是Autowired真正发挥作用的地方。容器会遍历这个Bean里所有标记了依赖注入的字段或方法逐个去容器里找对应的Bean然后注入进来。执行InitializingBean接口的afterPropertiesSet()或PostConstruct标注的方法以及自定义init-method。应用BeanPostProcessor后置处理器返回最终的Bean实例。第2步到第6步是实例化和初始化的本质差异。很多人踩过一个经典坑在PostConstruct方法里访问依赖的某个方法结果发现依赖对象是null。为什么因为如果你的PostConstruct方法所在Bean是通过CGLIB代理方式创建的代理对象的方法调用不会直接走真实对象逻辑更常见的原因是对步骤4和5的顺序理解不够——Spring先把所有依赖都注入完然后才调用PostConstruct所以如果依赖时没注入成功问题一定出在步骤4。Spring中两个Bean的生命周期顺序也有讲究BeanA依赖BeanB那么BeanB整体创建完成、进入可用状态后BeanA才能被创建。你不可能在BeanB还没初始化完就去注入BeanA这既违背了依赖关系方向也违背了容器的创建队列。理解了这个顺序你就应该明白为什么不能在一个Bean的构造方法里直接调用另一个Bean的初始化逻辑——因为依赖的初始化时机可能在你构造时还没到来。3.3 单例缓存与作用域为什么每次拿到的都是同一个对象Spring最常用的作用域是singleton单例。同一个BeanDefinition在容器内只维护一份实例后续请求全部返回同一个引用。这个缓存在容器内部叫singletonObjects本质是一个ConcurrentHashMap这就是运行时拿同一个Bean永远是同一个对象的底层原因。但有一类Bug很气人某个Controller里把UserService声明为实例变量并用Autowired注入——这没问题没问题是因为UserService是单例的会一直安全存在可如果你把某个短生命周期组件比如某次请求专用的数据容器注入到单例Bean里就会出问题。Spring对作用域的处理原则是单例Bean在创建时注入什么就一直是那个引用无论注入的对象本身是不是原型作用域。真正复杂的是另一个场景——单例Bean依赖原型Bean。你可以在单例Bean里注入一个Prototype作用域的Bean但注入的引用是固定的每次调用方法时用的都是同一个实例原型Bean的每次新创建特性完全没生效。这个问题我留在第5节专门分析这里先记住一个关键结论注入时机的快照机制。依赖注入只发生在Bean创建的那个时间点之后容器不会反复重新注入。3.4 几类常见生命周期扩展点别用错位置Spring的生命周期扩展点非常多我挑几个最常用的并给出它们最典型的应用场景免得大家踩坑PostConstruct在依赖注入完成之后、Bean对外提供服务之前执行的初始化逻辑。适合做依赖资源的校验、缓存的预热、配置的二次校验。InitializingBean接口功能和PostConstruct重叠但顺序上PostConstruct会更早执行一点。由于PostConstruct不需要实现接口我更推荐它。BeanPostProcessor作用于容器内所有Bean可以对每个Bean做统一的增强处理。典型的应用是AOP代理的创建就藏在这一环节容器在获得原始对象后通过后置处理器返回了代理对象业务代码拿到的是代理不是原始Bean。PreDestroy容器关闭前的清理逻辑比如释放连接池、注销钩子。DisposableBean效果同PreDestroy但不推荐直接实现接口用注解更干净。有一类很常见的面试题问Bean生命周期中PostConstruct和afterPropertiesSet和构造器谁先谁后答案依次是构造器 -PostConstruct-afterPropertiesSet。如果某个逻辑放在构造器里访问依赖的Bean大概率拿到的还是null因为依赖还没注入。4. 循环依赖与三级缓存全网最久热词背后的真相Spring三级缓存原理常年挂在热搜上面试官爱问开发者也爱背。但真正理解它的人不到两成。两成里面能在遇到循环依赖报错时快速定位并给出解决方案的又少一半。这一节我把来龙去脉讲透。4.1 什么是循环依赖为什么会报错循环依赖长这样Service public class ServiceA { private final ServiceB serviceB; public ServiceA(ServiceB serviceB) { this.serviceB serviceB; } } Service public class ServiceB { private final ServiceA serviceA; public ServiceB(ServiceA serviceA) { this.serviceA serviceA; } }创建ServiceA时发现需要ServiceB于是去创建ServiceB而ServiceB又需要ServiceA两个类互相等待对方先创建出来死锁了。Spring会直接抛BeanCurrentlyInCreationException。这里最核心的一句话为什么字段注入能解决循环依赖而构造器注入解决不了因为字段注入是把对象先new出来此时依赖字段还是null再回头填充属性。ServiceA先实例化成功——哪怕它的serviceB字段还没有值——ServiceB创建时发现需要ServiceA而ServiceA在缓存里已经有一个半成品了直接把这个半成品传给ServiceBServiceB顺利创建完成后再回头把完整的ServiceB注入给ServiceA的serviceB字段。整个过程虽然绕但最终两个Bean对象都完整了。构造器注入不行是因为构造器调用本身就在创建对象没有提前暴露半成品的机会。ServiceA调用构造器时就需要ServiceB可ServiceB的构造器又需要ServiceA两个都没法先new到一个半成品Spring也没办法。4.2 三级缓存名字吓人逻辑却很朴素Spring容器内部维护了三层Map分别叫singletonObjects、earlySingletonObjects、singletonFactories。很多人以为三级缓存是三个一样的缓存其实各自功能不同一级缓存singletonObjects存放创建完成的、完整的单例Bean。日常开发从容器里拿Bean最终都是从这层拿的。二级缓存earlySingletonObjects存放提前暴露的半成品Bean对象存在但属性尚未完全填充。三级缓存singletonFactories存放的是ObjectFactory类型的工厂对象它们能在需要时根据原始实例生成一个早期引用对象通常是代理对象的早期引用。为什么需要三级而不是只用两级有一个很深的点如果BeanA最终会被AOP生成代理对象那么在循环依赖发生时如果直接暴露原始Bean的半成品引用后期创建代理时就会造成外面引用的是原始对象容器最终缓存的是代理对象两者不一致业务逻辑会出奇怪的Bug。三级缓存的ObjectFactory可以在暴露早期引用的时候介入保证外部拿到的引用和最终对象是统一的要么都是原始对象要么都是代理对象。我这个解释可能比很多面试答案更透彻一层。你在实际工作中不需要手动碰这三层Map但遇到类似AOP代理导致循环依赖报错这种怪问题时能通过这个机制反推原因。4.3 模拟一次完整的循环依赖解析过程多Bing多走一遍假设ServiceA和ServiceB互相依赖且ServiceA经过了4.1的字段注入配置容器开始创建ServiceA实例化后将ObjectFactory对应的工厂放入三级缓存。填充ServiceA的属性发现需要ServiceB销毁当前创建流程转而创建ServiceB。ServiceB实例化完成同样放入三级缓存填充属性时发现需要ServiceA。ServiceB从三级缓存拿到ServiceA的工厂通过工厂获得ServiceA的早期引用可能经过AOP代理包装注入ServiceB的字段。ServiceB初始化完成存入一级缓存。回到ServiceA的填充流程把刚刚创建好的ServiceB注入ServiceA的字段ServiceA初始化完成存入一级缓存。整个流程里有一步特别奇妙ServiceA在步骤2的时候其实知道自己还没填充完毕但依然能把自己当前的早期引用借给ServiceB用。这种半路借引用的设计本质上是一种类似提前预约的思想——我还没完全准备好但先告诉你我的位置你先拿着用等我忙完再补齐细节。在实际生产中我遇到过一些循环依赖是通过Lazy解决的原理就是注入一个代理对象真正调用时才从容器获取目标Bean从而打断循环。Lazy作为一种常规解决方案偶尔有效但治标不治本重构设计、消除循环依赖才是根本。说实话把代码拆成几层绝大多数循环依赖根本不成立。5. 容器内的消失的Bean五个高频踩坑场景排雷实录这一节我从真实的项目排查经历里挑了五个最高频的问题。每一个都有人在群里问过每一个都值得你当成checklist记下来。5.1 NoUniqueBeanDefinitionException两个同类Bean容器不知道给谁public interface MessageSender { void send(String msg); } Component public class SmsSender implements MessageSender { ... } Component public class EmailSender implements MessageSender { ... }然后在业务类里写Autowired private MessageSender messageSender;启动时直接抛NoUniqueBeanDefinitionException——容器里有SmsSender和EmailSender两个候选它不知道该注入谁。解决方案有三种按推荐程度排序用Primary标记首选实现。在SmsSender上加上Primary容器默认优先选择它。适合绝大多数场景用默认实现、偶尔换另一套的情况。配合Qualifier(smsSender)显式指定Bean名。需要把具体实现写死适合不同场景需要明确不同实现的逻辑。使用ObjectProviderT延时获取拿到所有实现运行时动态选择。我自己的习惯是真正需要动态选择时直接注入ListMessageSender遍历时根据业务场景挑一个。比如策略模式里每种支付方式都做成一个Bean容器会自动把同类型的多个Bean按顺序注入进List里这是Spring容器自带的能力做策略模式极其好用——加一个新的策略实现类不需要改任何调用方的代码容器自动扩容列表。5.2 BeanDefinitionStoreException / BeanCreationException一个Bean都创建不了的时候有时候启动直接整体失败日志里写着类似Error creating bean with name xxxBean with name xxx has been injected into other beans ...。这类问题要抓住两个排查方向方向一构造器或PostConstruct里跑了异常代码比如连接数据库失败、读取配置文件失败。Spring的逻辑是一个Bean初始化失败它就拒绝启动因为依赖它的其他Bean也可能带病工作。方向二依赖关系里有硬循环依赖且用了构造器注入。上一节讲了原理这里直接说排查最快的方法——看看报错堆栈最后的正文如果是两个类的创建状态互相嵌套那就是循环依赖如果不是十有八九是初始化代码里抛了没捕获的异常。有一个小技巧遇到构造器注入导致的循环依赖先别急着加Lazy而是看一眼两个类的模块归属。我之前一个项目里循环依赖出现在Controller互相调用API的场景——A控制器为了调B控制器的某个查询方法注入了B控制器B控制器又为了调A控制器的某个方法注入了A控制器。这个场景重构很简单把公共逻辑下沉到Service层控制器之间不要互相注入循环依赖瞬间消失。5.3 单例注入原型的失真你以为是新的其实一直是同一个这是Spring开发里最经典的想当然Bug。Component Scope(prototype) public class RequestContext { ... } Component public class HttpClient { Autowired private RequestContext requestContext; public void call() { // 这里你以为每次拿到的是新的RequestContext // 但如果在某个单例Bean里注入HttpClient // 那这个RequestContext早就被固定住了 } }单例Bean在创建时只注入一次依赖所以无论HttpClient怎么被调用里面持有的RequestContext都是当初那个。Scope(prototype)的白搭了。万能解法有三种注入ObjectProviderRequestContext每次通过getObject()获取新的实例。注入ApplicationContext不推荐会让代码耦合容器每次手动getBean(RequestContext.class)。配置Scope(value singleton, proxyMode ScopedProxyMode.TARGET_CLASS)给依赖方生成一个代理对象每次调用方法时都从容器获取目标Bean的一个新实例。第三种方案用的多但要注意它生成的是代理对象会有一些方法调用开销且equals、hashCode等方法的语义都可能受影响。能用第一种方案解决就不要先用第三种。5.4 泛型Bean注入容器不知道你要哪个T有时候你在一个泛型接口上做多个实现然后想注入一个具体泛型版本的Bean。public interface ConverterT { T convert(String source); } Component public class UserConverter implements ConverterUser { ... } Component public class OrderConverter implements ConverterOrder { ... }如果只写Autowired private ConverterOrder converter;容器同样会懵——它不知道你是要UserConverter还是OrderConverter。正解是配合Qualifier显式指定Bean名比如Qualifier(userConverter)。更优雅的做法是Spring 4.0之后支持的ResolvableType能力容器会把ConverterUser和ConverterOrder当成两个不同类型所以你可以注入ListConverterUser泛型列表来拿到所有User转换器也能直接注入ConverterUser前提是Spring能通过ResolvableType解析出这个泛型类型。但泛型信息在运行期是被擦除的Spring靠的是类定义里的signature属性来做推断所以一旦继承体系复杂了照样会有歧义。遇到这类问题记着一个口诀泛型加Qualifier区别对待不乱配。5.5 Value读不到配置你以为是注入的问题其实是配置源问题这个坑很多人容易归咎于依赖注入失败其实不是。它的问题在Spring的配置处理环节。Value(${my.config.value})读不到配置时启动阶段就会报Could not resolve placeholder或者注入的是null/默认值。排查顺序我建议这样固定下来这个配置在哪个文件里application.yml还是application.properties确认配置文件有没有被loaded。配置文件路径对不对Spring Boot默认读classpath根目录下的application.yml如果你用了多个配置文件先用spring.profiles.active确认激活的环境。配置前缀和key拼写是否完全一致大小写、点号、中划线任何一个字符不对都读不到。配置里有没有特殊字符比如#、:导致YAML解析异常用了ConfigurationProperties的数据类检查有没有正确加Component或EnableConfigurationProperties。有一次我排查一个线上问题折腾了两小时最后发现是同事在YAML里用了${DB_URL:jdbc:mysql://localhost}这种带默认值的语法但默认值本身写错了而后来环境变量恰好也没设置于是所有用到这个配置的Bean全部以默认值状态在跑业务数据当然不对。经验教训是每次启动都留意日志里有没有WARN级别的placeholder替换警告很多问题早就提示了只是没人看。6. 进阶玩法从能用到用得好的依赖注入姿势6.1 Lazy延迟注入的适用场景和副作用Lazy加在Autowired上可以延迟Bean的创建甚至延迟注入依赖本身Service public class ReportService { private final AuditReportGenerator reportGenerator; public ReportService(Lazy AuditReportGenerator reportGenerator) { this.reportGenerator reportGenerator; } }这里Lazy注入的是一个代理对象真正第一次调用AuditReportGenerator的方法时才会在这个代理背后创建真实Bean。典型使用场景有两个一是打破循环依赖前面提过二是启动加速——某些重量级Bean确实没必要在容器启动时全部创建完全可以等用到了再初始化。副作用是理解起来有门槛尤其在调试时你拿到的是一个CGLIB代理类看堆栈时方法调用会多一层代码容易让人困惑。另一个问题是如果代理Bean的初始化逻辑里抛了异常报错时间会从启动阶段推迟到第一次业务调用——线上故障没了预知性这是我最担心的。所以能用显式初始化预热的就不要依赖Lazy来掩耳盗铃。6.2 条件注入让容器自己决定该装配谁Spring Boot的自动装配体系里条件注入是灵魂。ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty这些注解本质上就是根据运行时环境动态决定要不要创建某个Bean。举一个非常实战的例子Configuration public class EmailConfig { Bean ConditionalOnProperty(name notification.email.enabled, havingValue true) public EmailSender emailSender() { return new EmailSender(); } }当配置项notification.email.enabledtrue时容器才会装配EmailSender。这个写法让配置驱动装配业务代码里不需要写if else判断功能是否启用。结合ConditionalOnMissingBean你还能实现用户可以自定义覆盖默认Bean的扩展点框架提供一个默认实现但用户在配置类里显式声明自己的Bean时Spring优先采用用户的框架默认那个自动失效。这套机制的实际价值我在一个多环境部署场景里体会很深开发环境不启用消息队列测试环境启用一个假的队列实现生产环境启用真实队列三个环境共用同一套代码只是配置文件不同容器自动完成了不同依赖方的装配。如果不理解条件注入你可能得在代码里写一堆环境判断丑且难维护。6.3 ObjectProvider处理可选依赖的正确姿势Service public class PaymentService { private final ListPaymentStrategy strategies; public PaymentService(ObjectProviderListPaymentStrategy strategyProvider) { // 延迟获取容器初始化时不会强制要求所有策略都就绪 this.strategies strategyProvider.getIfAvailable(Collections::emptyList); } }ObjectProvider最大的价值是处理依赖可能存在可能不存在的集合。类的构造器里用一个ObjectProvider接住可选依赖运行时通过getIfAvailable()或ifAvailable()判断有没有值。这比直接注入List更灵活——直接注入List时容器会把容器里所有该类型的Bean给你但如果某个Bean初始化顺序有问题你在构造需求里拿到的可能是null或者不完整的。另外一个高频用法是让单例注入原型的问题更顺滑前面5.3提过。ObjectProvider配合Java 8的Supplier范式代码可读性很高我个人强烈推荐在需要用运行时动态获取Bean的场景里优先考虑它而不是直接注入ApplicationContext去手动getBean后者把代码和容器耦合在了一起测试时要mock整个容器痛苦度翻倍。6.4 Bean的替换与增强Primary Fallback Profile的协同作战复杂系统里同一个接口的多个实现经常需要分环境装配。Profile可以按激活的环境拆分Primary可以指定默认优先Profile(!prod)这种反向写法还能表达非生产环境才装配的逻辑。举个例子Configuration public class SmsConfig { Bean Profile(!prod) Primary public SmsSender mockSmsSender() { return new SmsSender(mock); } Bean Profile(prod) Primary public SmsSender realSmsSender() { return new SmsSender(real); } }开发环境跑mock版生产环境跑真实版业务代码完全不用感知。这套组合拳的价值在于我们做活动项目时——开发测试联调阶段用mock实现保证稳定性发版前切profile就切到真实实现改动的是配置而不是代码。6.5 注入元数据注解让Spring理解你更深层次的需求除了Autowired和ResourceSpring还提供了一类偏底层的注入注解比如Value、Qualifier、Lookup等。Lookup是一个很容易被忽略但很好用的功能它在单例Bean内每次调用时从容器获取新实例原型Bean本质上解决了5.3的困境还不需要代理对象Component public abstract class AbstractProcessor { Lookup protected abstract PrototypeBean getPrototypeBean(); public void process() { PrototypeBean bean getPrototypeBean(); // 每次都是新的 bean.run(); } }Lookup的实现机制是Spring通过CGLIB生成子类覆写这个抽象方法方法内从容器获取对应Bean。由于是子类覆写原类的抽象方法不能是private。这个方案比注入代理对象更轻量也让代码意图更直接。不过它要求类是abstract或者方法能被覆写这给代码结构带来了一点限制只能在选定场景用。7. 一个真实的依赖注入重构案例从面条代码到清晰架构讲了这么多原理最后放一个我亲手经历过的重构案例把前面的知识串起来。7.1 重构前的状态一个Service里new了10个对象老代码大概长这样名字我脱敏了public class UserOrderService { public void placeOrder(OrderDTO dto) { UserMapper userMapper new UserMapper(); OrderMapper orderMapper new OrderMapper(); InventoryClient inventoryClient new InventoryClient(); CouponService couponService new CouponService(); // 又因为有缓存还给缓存客户端直接new了一个实例 RedisClient redisClient new RedisClient(localhost, 6379); User user userMapper.findById(dto.getUserId()); // 一大堆业务逻辑... } }问题一眼就能看出来每次调用placeOrder都重新创建所有依赖对象。RedisClient每次new一个连接连接数分分钟打满InventoryClient每次new一个HTTP客户端底层连接池完全没复用而且这些依赖全部写死在方法里测试根本没法做——你没法mock一个new出来的对象。7.2 重构后的形态让容器管理一切我做的第一件事把所有的依赖对象改造成Spring管理的Bean类的构造函数只接收接口不接收具体实现。Service public class UserOrderService { private final UserMapper userMapper; private final OrderMapper orderMapper; private final InventoryClient inventoryClient; private final CouponService couponService; private final RedisClient redisClient; public UserOrderService(UserMapper userMapper, OrderMapper orderMapper, InventoryClient inventoryClient, CouponService couponService, RedisClient redisClient) { this.userMapper userMapper; this.orderMapper orderMapper; this.inventoryClient inventoryClient; this.couponService couponService; this.redisClient redisClient; } public void placeOrder(OrderDTO dto) { // 业务逻辑不变依赖都来自容器 } }然后处理RedisClient和InventoryClient的连接复用问题把它们配置成单例Bean连接生命周期完全交给容器管理。这样一来同一时刻全系统的HTTP连接和Redis连接只有固定的几个资源使用率瞬间降下来。7.3 可测试性带来的直接收益重构之后单元测试终于能写了。用MockitoUserMapper userMapper mock(UserMapper.class); OrderMapper orderMapper mock(OrderMapper.class); InventoryClient inventoryClient mock(InventoryClient.class); CouponService couponService mock(CouponService.class); RedisClient redisClient mock(RedisClient.class); UserOrderService service new UserOrderService( userMapper, orderMapper, inventoryClient, couponService, redisClient );五秒内创建被测对象所有依赖都是可控制的替身。这在重构前完全不可能。实际效果怎么样重构前这个模块几乎没有任何单元测试重构后一周内我补充了40多个测试用例覆盖了下单流程里的各种分支。上线后的回归测试效率提高了一大截这个收益比代码整洁度本身更有说服力。7.4 这个案例里踩到的一个坑和最终解法重构期间我踩了一个典型坑InventoryClient被设计成连接第三方库存系统的客户端依赖一些第三方配置结果我在构造器里做了一次远程调用校验配置是否正确——这导致容器启动时任何依赖它的Bean全部初始化失败。线上环境配置是对的所以启动正常但测试环境没有第三方服务任何测试一碰这个类就崩。后来我把远程校验逻辑挪到了PostConstruct而不是构造器里然后测试环境用Profile(test)注册一个Mock版本。这次的教训很值得记下来构造器里只做纯内存操作不依赖外部资源外部资源连接和校验统一放到PostConstruct再通过Profile等手段让不同环境装配不同实现。我自己在做了大量Spring项目之后最大的体会是依赖注入的根本目的是让代码的依赖关系显式化、可替换化、可测试化。这三点做到位了架构质量基本就有了。如果你把Autowired当成省去new的快捷方式那你只能体验它的便利体会不到它背后那套容器机制蕴含的设计哲学。但当你真正踩过循环依赖、可选依赖、多实现装配这些坎之后你会越发认可这套控制反转思想的精妙——它不是让代码变简单了而是让代码的复杂度被放到了正确的位置上。希望这篇聊得足够细能帮你在实际编码中少走一些弯路。如果你也有被某个依赖注入问题折磨过欢迎按上面的排查思路再走一遍大概率能找到答案。