在Java后端开发领域，Spring框架几乎已经成为“事实上的标准”。据统计，超过80%的Spring核心模块直接或间接依赖IoC容器提供的服务-38。无论是刚入门的初学者，还是准备面试的求职者，抑或是正在重构遗留系统的开发工程师，理解依赖注入（Dependency Injection，简称DI） 与控制反转（Inversion of Control，简称IoC） 都是绕不开的核心课题。

很多开发者陷入了一个尴尬的困境：天天在代码中写@Autowired，但被问到“IoC和DI有什么区别”时却支支吾吾；会用Spring，却不懂其底层原理；面试时概念混淆，丢掉了本该拿下的分数。

本文将用通俗的语言、直观的代码对比和清晰的原理分析，从概念定义、核心区别、代码示例到底层实现，带你彻底吃透Spring依赖注入与IoC，从“会用Spring”升级为“理解Spring”。

一、痛点切入：传统开发模式的困境

先来看一段典型的传统Java代码：

// 传统开发方式：紧耦合
public class OrderService {
    // 硬编码依赖，直接new对象
    private PaymentService payment = new AlipayService();
    private Logger logger = new FileLogger("/tmp/log");
    
    public void pay() {
        payment.process();  // 想换成微信支付？必须改代码重新编译！
    }
}

这种写法存在三个致命问题：

1. 高耦合：OrderService与具体实现类AlipayService强绑定，替换实现必须修改源码

2. 难以测试：单元测试无法替换为Mock对象，测试必须依赖真实环境

3. 可维护性差：随着对象依赖链变长，手动管理所有依赖让代码臃肿不堪-1

想象一下：你需要一个对象A，但A依赖B和C，而B又依赖D和E……这种依赖链一旦复杂起来，手动new对象的工作量将彻底失控-10。这正是依赖注入要解决的核心问题。

二、核心概念讲解：控制反转（IoC）

2.1 标准定义

IoC（Inversion of Control，控制反转）是一种设计思想，它将传统上由程序代码直接操控的对象调用权交给外部容器（如Spring IoC容器）来统一管理-2。

简单说，就是将对象的创建、依赖关系的组装控制权从应用程序代码中反转到外部容器-22。

2.2 关键词拆解

• “控制” ：指的是对象的创建权、生命周期管理权、依赖装配权

• “反转” ：相对于传统“正转”（在类内部主动new对象），现在是“被动接收”——由容器把对象“送上门”

2.3 生活化类比：婚介所

传统的“正转”模式，就像你自己去找对象——你得挨个认识、筛选、确认关系，所有事情亲力亲为。

而IoC模式，就像你去婚介所登记需求： “我需要一个会做饭的对象。” 婚介所（IoC容器）会帮你筛选、匹配，最后把符合条件的人“注入”到你身边。你不需要关心对方从哪里来、怎么找到的，只需要声明需求即可-25。

这就是 “好莱坞原则” —— “别找我们，我们会找你” （Don‘t call me， I’ll call you）-10。

三、关联概念讲解：依赖注入（DI）

3.1 标准定义

DI（Dependency Injection，依赖注入）是一种设计模式，是IoC的具体实现方式。它由容器在运行期间动态地将依赖关系注入到对象中-。

3.2 三种注入方式

Spring主要支持三种依赖注入方式：

3.3 IoC与DI的关系总结

一句话总结：IoC是“指导思想”，DI是“落地操作”；IoC回答“谁控制”，DI回答“如何传” -2。

四、代码示例：传统模式 vs IoC+DI模式

4.1 传统模式（紧耦合）

// 依赖对象
public class UserDaoImpl implements UserDao {
    public void queryUser() {
        System.out.println("查询用户信息");
    }
}

// 目标对象：主动new依赖
public class UserServiceImpl implements UserService {
    private UserDao userDao = new UserDaoImpl();  // 硬编码
    
    public void queryUser() {
        userDao.queryUser();
    }
}

// 测试类：手动创建所有对象
public class Test {
    public static void main(String[] args) {
        UserService userService = new UserServiceImpl();
        userService.queryUser();
    }
}

4.2 IoC+DI模式（Spring容器管理）

// 依赖对象：声明为Bean
@Repository
public class UserDaoImpl implements UserDao {
    public void queryUser() {
        System.out.println("查询用户信息");
    }
}

// 目标对象：依赖由容器注入
@Service
public class UserServiceImpl implements UserService {
    // 仅声明依赖，不主动创建
    private UserDao userDao;
    
    // 构造器注入（Spring 4.3+ 可省略@Autowired）
    public UserServiceImpl(UserDao userDao) {
        this.userDao = userDao;
    }
    
    public void queryUser() {
        userDao.queryUser();
    }
}

// 测试类：从容器中获取对象
public class Test {
    public static void main(String[] args) {
        ApplicationContext context = 
            new AnnotationConfigApplicationContext(AppConfig.class);
        UserService userService = context.getBean(UserService.class);
        userService.queryUser();  // 依赖已自动注入
    }
}

核心变化：对象的创建、依赖的装配、生命周期的管理，全部交给Spring容器负责，开发者只需声明“我需要什么依赖”-1。

五、注解详解：@Autowired vs @Resource

在日常开发中，@Autowired和@Resource是最常用的两个依赖注入注解。它们的查找逻辑截然不同：

5.1 @Autowired（Spring原生）

• 查找顺序：先按类型（byType）查找 → 再按名称（byName）查找

• 支持required属性：@Autowired(required=false)允许依赖为空-11

• 配合注解：多Bean时用@Qualifier指定名称，或用@Primary标记首选-11

@Service
public class UserService {
    // 按类型查找，多个同类型时按字段名"userDao"查找
    @Autowired
    private UserDao userDao;
    
    // 显式指定名称
    @Autowired
    @Qualifier("redisUserRepository")
    private UserRepository userRepository;
}

5.2 @Resource（JSR-250标准）

• 查找顺序：先按名称（byName）查找 → 再按类型（byType）查找

• 不支持required=false：找不到Bean直接抛异常

• 不能用于构造器：只能标注字段和Setter方法-16

@Service
public class UserService {
    // 先查找名为"userDao"的Bean
    @Resource
    private UserDao userDao;
    
    // 显式指定名称
    @Resource(name = "orderService")
    private OrderService orderService;
}

5.3 快速对比

六、底层原理：Spring容器如何实现依赖注入

6.1 反射机制是核心

Spring依赖注入的底层依赖Java反射机制。容器在运行时通过反射调用构造方法创建Bean实例，并通过反射为字段赋值-38。

6.2 Bean生命周期

一个Bean从创建到销毁经历以下关键阶段-37：

1. 实例化：通过反射调用构造方法创建实例

2. 属性填充：通过依赖注入为Bean设置属性值（@Autowired等在此阶段处理）

3. 初始化：Aware回调 → BeanPostProcessor前置 → init-method → BeanPostProcessor后置

4. 销毁：容器关闭时触发destroy方法

6.3 容器架构

• BeanFactory：基础容器接口，定义最核心的功能契约

• ApplicationContext：增强接口，集成了国际化、事件发布、资源加载等企业级特性-38

• BeanDefinition：每个Bean对应一个元数据对象，存储类名、作用域、依赖关系等配置信息-38

6.4 循环依赖的三级缓存

Spring通过三级缓存解决单例Bean的循环依赖问题-38：

• 一级缓存（singletonObjects） ：存放完整单例对象

• 二级缓存（earlySingletonObjects） ：存放提前暴露的早期对象

• 三级缓存（singletonFactories） ：存放对象工厂

⚠️ 注意：Spring只能解决单例作用域下通过Setter/字段注入产生的循环依赖，构造器注入的循环依赖无法解决-。

七、面试要点速记（踩分点）

Q1：什么是IoC和DI？它们有什么关系？

标准答案：

• IoC（控制反转） 是一种设计思想，将对象的创建和依赖管理权从程序代码转移到外部容器-22

• DI（依赖注入） 是IoC的具体实现方式，由容器动态地将依赖对象注入到组件中-22

• 关系：IoC是“指导思想”，DI是“落地操作”。DI是IoC最主流的实现手段-2

Q2：@Autowired和@Resource有什么区别？

标准答案：

• @Autowired是Spring原生注解，按类型优先查找；@Resource是Java标准注解，按名称优先查找-11

• @Autowired支持required=false；@Resource不支持，找不到直接抛异常

• @Resource不能用于构造器注入-16

Q3：Spring推荐哪种注入方式？为什么？

标准答案：

• 推荐构造器注入（Spring 4.x+官方明确推荐）-16

• 原因：依赖不可变（可加final）、测试友好（直接new Mock对象）、避免隐藏依赖

• 字段注入虽然写法简洁，但存在“隐藏依赖、无法加final、测试必须启动容器”等问题-16

Q4：Spring如何解决循环依赖？

标准答案：

• 通过三级缓存机制解决（singletonObjects → earlySingletonObjects → singletonFactories）

• 前提条件：Bean必须是单例作用域，且依赖方式为Setter或字段注入

• 构造器注入的循环依赖无法解决，会抛出BeanCurrentlyInCreationException-

Q5：Spring DI的底层实现原理是什么？

标准答案：

• 基于Java反射机制，在运行时通过反射调用构造器创建实例、为字段赋值-38

• 核心接口：BeanFactory（容器基础）和ApplicationContext（增强容器）

• 通过BeanPostProcessor扩展点处理@Autowired等注解-16

八、2026年最新实践趋势

随着Spring框架的持续演进，依赖注入的最佳实践也在更新：

1. 构造器注入成为绝对主流：Spring 6.x进一步强化了构造器注入的推荐地位，字段注入正被逐步淘汰-

2. Jakarta注解支持：从Spring 6.x起，JSR-330标准（@Inject注解）已成为内置功能，无需额外引入依赖-

3. AI辅助开发中的松耦合：在Cursor、GitHub Copilot等AI IDE环境下，依赖注入帮助构建更松耦合的代码结构-

九、总结

回顾全文，我们梳理了以下核心知识点：

掌握依赖注入不仅是理解Spring的起点，更是写出高内聚低耦合代码的关键能力。希望本文能帮助你从“会用Spring”升级为“理解Spring”！

💡 下篇预告：Spring AOP面向切面编程深度解析——从动态代理到@Transactional原理。