北京时间 2026-04-08 | 阅读时长约 10 分钟

Spring 作为 Java 后端开发的“基石框架”，其核心价值在于解耦代码、简化开发。统计显示，超过 80% 的 Spring 核心模块直接或间接依赖 IoC 容器提供的服务，从 AOP 代理的自动创建到事务管理的拦截器织入，再到 MVC 控制器的请求映射，这些功能的实现都建立在容器管理的 Bean 生命周期之上-3。理解 IoC 与 DI，不仅是用好 Spring 的基础，更是理解 Spring 底层原理、写出高内聚低耦合代码的关键。

然而很多开发者在学习 Spring 时，常常面临这样的困境：会用 @Autowired，却说不清依赖注入到底“怎么注”；知道 IoC 是控制反转，但面试时一问底层原理就卡壳；概念混淆——IoC 和 DI 到底什么关系？反射又扮演了什么角色？

本文是 Spring 核心技术系列的第一篇，将系统讲解 IoC（Inversion of Control，控制反转）与 DI（Dependency Injection，依赖注入）的核心概念、底层原理（重点剖析反射机制的落地应用）以及高频面试考点，帮助你从“会用 Spring”升级为“理解 Spring”。

痛点切入：为什么需要 IoC 和 DI？

我们先看一个没有使用 Spring 的传统示例：

// 数据访问层接口
public interface AccountDAO {
    int addAccount();
}

// 数据访问层实现类
public class AccountDAOImpl implements AccountDAO {
    @Override
    public int addAccount() {
        System.out.println("添加用户成功");
        return 1;
    }
}

// 业务逻辑层——存在严重耦合问题！
public class AccountService {
    public int addAccount() {
        // 🔴 硬编码：直接依赖具体实现类
        AccountDAO accountDAO = new AccountDAOImpl();
        return accountDAO.addAccount();
    }
}

// 测试类
public class Test {
    public static void main(String[] args) {
        AccountService accountService = new AccountService();
        accountService.addAccount();
    }
}

这段代码有什么问题？

1. 硬编码依赖：AccountService 通过 new 关键字直接创建 AccountDAOImpl 对象，导致业务逻辑层与数据访问层之间耦合度过高-22。

2. 扩展性差：若要从 MySQL 切换至 Oracle 数据源，必须修改 AccountService 内部的代码，违反了“对扩展开放，对修改关闭”的设计原则-2。

3. 测试困难：无法轻松地替换为 Mock 对象进行单元测试。

4. 对象生命周期管理混乱：多个类可能重复创建相同的重量级对象，无法集中管理资源和配置。

一句话总结：对象自己负责查找或创建它需要的依赖，是传统开发模式的典型特征，也是高耦合的根源-27。

这就引出了一个核心问题：能否让业务类只依赖抽象接口，而不依赖具体实现？能否让对象的创建和依赖管理脱离业务代码？

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

IoC（Inversion of Control，控制反转） 是一种设计思想。其核心是：对象的创建与依赖关系的管理，不再由程序代码主动控制，而是交给外部容器来完成-4。

🌰 生活类比：传统开发就像“自己办聚餐”——需要自己列清单、去超市采购食材（new 对象）、亲手做菜（组装依赖），少买一样菜就没法完成。IoC 模式就像“找上门厨师”——你只需告诉厨师“周末中午 10 人聚餐，要 3 个热菜”（声明需求），厨师会自行采购、备菜、做菜，你把精力放在招呼客人上（专注业务逻辑）-42。

IoC 的核心是“控制权的转移”：将对象的创建权、依赖的装配权、生命周期的管理权，从业务逻辑代码中转移到 Spring 容器-2。开发者只需专注于业务逻辑本身。

IoC 解决了什么问题？

• 将对象与对象之间的依赖关系从代码中剥离，通过配置或注解管理，使业务逻辑更纯粹。

• 大幅降低组件间的耦合度，提升模块的可测试性。

• 实现对象生命周期的统一管理，避免重复创建和资源浪费-2。

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

DI（Dependency Injection，依赖注入） 是 IoC 设计思想的具体实现方式。它描述了容器如何“注入”对象所依赖的其他对象-27。

简单来说：容器在创建 Bean 时，自动将依赖的 Bean 注入到目标 Bean 中（比如通过 @Autowired）-1。

Spring 中 DI 的三种主要形式：

💡 最佳实践：构造器注入是最推荐的方式——清晰、利于测试，且能够避免循环依赖的隐患-43。

对比传统模式与 DI 模式：

// ❌ 传统方式：手动创建依赖（高耦合）
public class UserService {
    private UserDao userDao = new UserDaoImpl();  // 自己负责创建
}

// ✅ DI 方式：依赖由容器注入（低耦合）
@Service
public class UserService {
    @Autowired
    private UserDao userDao;  // 仅声明需要什么，容器自动注入
}

DI 的优势：

• 对象只声明“需要什么依赖”，由容器负责在运行时提供（注入）-27。

• 使代码更模块化、更易测试、更易维护。

• 配合接口使用，可实现运行时多态，进一步增强灵活性-26。

IoC 与 DI 的关系：一句话概括

IoC 是设计思想，DI 是实现方式；IoC 是“思想”，DI 是“手段”-5。

两者总是一起出现：如果 A 无法拿到 B，程序是无法正常运行的。所以 IoC 和 DI 通常被同时讨论-。

代码示例：从传统到 Spring DI 的演进

以下是一个完整的对比示例，展示从传统方式到 Spring DI 方式的演进：

// ==================== 公共接口 ====================
public interface MessageService {
    void send(String message);
}

// ==================== 传统方式 ====================
public class TraditionalApp {
    // ❌ 硬编码依赖，每次都要手动 new
    public void sendMessage(String msg) {
        MessageService service = new EmailService();  // 写死了具体实现
        service.send(msg);
    }
}

// ==================== Spring DI 方式 ====================
@Service
public class EmailService implements MessageService {
    @Override
    public void send(String message) {
        System.out.println("发送邮件：" + message);
    }
}

@Service
public class NotificationService {
    // ✅ 依赖声明，容器自动注入
    private final MessageService messageService;
    
    @Autowired  // 构造器注入
    public NotificationService(MessageService messageService) {
        this.messageService = messageService;
    }
    
    public void notify(String message) {
        messageService.send(message);
    }
}

// 测试类
@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        ApplicationContext context = 
            new AnnotationConfigApplicationContext(AppConfig.class);
        NotificationService service = 
            context.getBean(NotificationService.class);
        service.notify("Hello Spring DI!");
    }
}

核心变化一目了然：控制权从开发者转移到 Spring 容器——对象的创建、依赖的装配、生命周期的管理，全由容器负责-2。

底层原理：反射技术是 IoC/DI 的基石

理解了 IoC 和 DI 的概念与关系，接下来回答一个关键问题：Spring 容器到底是如何做到“自动创建对象并注入依赖”的？

答案是：Java 反射机制（Reflection）。

反射是 Spring Boot 框架实现核心功能的底层基础，依赖注入、控制反转、AOP、注解解析等核心特性都大量依赖反射。尽管反射存在性能损耗，但 Spring 通过一系列优化手段将其影响降到最低-11。

反射在 IoC/DI 中的具体应用：

1. 对象创建（实例化 Bean）：Spring 扫描带有 @Component、@Service 等注解的类后，通过反射获取类的 Class 对象，再调用构造器动态创建实例，无需手动 new 对象-11。

// Spring 底层简化示例
Class<?> clazz = Class.forName("com.example.UserService");
Constructor<?> constructor = clazz.getConstructor();
Object instance = constructor.newInstance();  // 反射创建实例

1. 依赖注入：当类中存在 @Autowired 标注的字段或方法时，Spring 通过反射访问私有字段并注入依赖对象（调用 Field.setAccessible(true)），或调用 Setter 方法完成注入（通过 Method.invoke()）-11。

// 依赖注入的简化示例
Field field = targetClass.getDeclaredField("userDao");
field.setAccessible(true);           // 突破私有访问限制
field.set(beanInstance, daoInstance); // 注入依赖

1. 注解解析：Spring 通过 Class.getAnnotations() 获取类、方法、字段上的注解，进而实现配置解析和功能增强-11。

关于反射的更多细节（如 JDK 动态代理与 CGLIB 的区别、三级缓存如何解决循环依赖等），将在本系列后续文章中详细展开。

高频面试题与参考答案

Q1：谈谈你对 Spring IoC 和 DI 的理解，它们的区别是什么？

参考答案：IoC（控制反转）是一种设计思想，核心是将对象的创建权、依赖管理权从应用程序代码“反转”给 Spring 容器管理。DI（依赖注入）是 IoC 的具体实现方式，指容器在创建对象时自动将该对象需要的依赖注入进去。区别在于：IoC 是“思想”，回答“谁来管理对象”；DI 是“手段”，回答“如何把依赖给对象”-。

Q2：IoC 容器的底层是如何实现的？

参考答案：IoC 容器底层依赖 Java 反射机制。启动时，容器扫描配置元数据（XML 或注解），解析出需要管理的类信息，封装为 BeanDefinition 并注册到注册表中。随后通过反射调用构造器实例化 Bean，再通过反射（Field.setAccessible() 或 Method.invoke()）完成依赖注入。Spring 还通过 BeanFactory 接口体系（如 ApplicationContext）提供完整的容器管理能力-1-11。

Q3：IoC 有哪些优点？

参考答案：（1）解耦：对象之间不再直接依赖具体实现，而是依赖抽象接口；（2）提高可测试性：可以轻松替换为 Mock 对象进行单元测试；（3）集中管理生命周期：避免重复创建对象，便于统一配置和资源释放；（4）增强代码灵活性：通过配置切换不同的实现类，无需修改业务代码-2-22。

Q4：@Autowired 和 @Resource 的区别是什么？

参考答案：@Autowired 是 Spring 提供的注解，默认按类型（byType） 装配；@Resource 是 JDK 提供的注解（JSR-250），默认按名称（byName） 装配。当存在多个同类型 Bean 时，@Autowired 需要配合 @Qualifier 指定名称，而 @Resource 可直接通过 name 属性指定-。

总结

回顾全文，核心知识点梳理如下：

• IoC（控制反转）：一种设计思想，核心是“控制权的转移”——将对象的创建、依赖管理、生命周期管理交给 Spring 容器-4。

• DI（依赖注入）：IoC 的具体实现方式，指容器将依赖对象主动“注入”给目标对象-1。

• IoC 与 DI 的关系：IoC 是设计思想，DI 是实现手段；IoC 回答“谁来管理对象”，DI 回答“如何把依赖给对象”-5。

• 底层技术支撑：Java 反射机制，包括动态创建实例、访问私有字段、调用方法等，是 Spring 实现 IoC/DI 的核心技术基础-11。

• 三种注入方式：构造器注入（推荐）、Setter 注入、字段注入，各有适用场景-43。

💡 易错点提醒：不要把 IoC 等同于 DI！IoC 是一种思想，DI 是实现这一思想的一种具体手段。在面试和工作中，清晰地分辨二者区别是基本要求。

预告：下一篇将深入剖析 Spring IoC 容器的启动流程，详解 BeanDefinition 的注册过程、三级缓存如何解决循环依赖，以及 BeanPostProcessor 扩展点的应用。欢迎持续关注！