2026年4月：一文搞懂Spring IoC与DI——原理剖析+代码实战+面试高频考点

小编 2026年04月21日 04:36 4 0

目标读者：技术入门/进阶学习者、在校学生、面试备考者、Java/Spring技术栈开发工程师

文章定位：技术科普 + 原理讲解 + 代码示例 + 面试要点，兼顾易懂性与实用性

引言

无论你是刚接触Spring框架的新手，还是正在准备Java面试的求职者，一定遇到过这两个绕不开的术语——IoC（Inversion of Control，控制反转）和DI（Dependency Injection，依赖注入）。很多初学者甚至有一定经验的开发者，常常将二者混为一谈：能用@Autowired注解把对象“变”出来，却讲不清它为什么存在、底层怎么工作，面试时被追问概念细节就支支吾吾。这正是技术学习中最常见的痛点：只会用，不懂原理；概念易混淆，面试答不出。

本文将带你从零开始，系统拆解Spring IoC与DI的完整知识链路：从传统开发的痛点出发，理清IoC与DI的概念与关系，用可运行的代码示例对比新旧实现方式，再深入到底层原理，最后提炼面试高频题的标准答案。读完本文，你不仅能彻底理解这两个核心概念，还能从容应对面试官的任何追问。

一、痛点切入：传统开发的“new”地狱

在理解IoC之前，先看一个典型的传统开发场景——造一辆车：

// 轮子类
public class Tire {
    private int size;
    public Tire(int size) {
        this.size = size;
        System.out.println("tire init, size: " + size);
    }
}

// 底盘类
public class Bottom {
    private Tire tire;
    public Bottom(int size) {
        this.tire = new Tire(size);
        System.out.println("bottom init...");
    }
}

// 车身框架类
public class Framework {
    private Bottom bottom;
    public Framework(int size) {
        this.bottom = new Bottom(size);
        System.out.println("framework init...");
    }
}

// 汽车类
public class Car {
    private Framework framework;
    public Car(int size) {
        this.framework = new Framework(size);
        System.out.println("car init...");
    }
    public void run() {
        System.out.println("car run...");
    }
}

// 测试入口
public class Main {
    public static void main(String[] args) {
        Car car = new Car(21);
        car.run();
    }
}

这段代码暴露了传统开发模式的核心问题：高耦合。Car依赖Framework，Framework依赖Bottom，Bottom依赖Tire。当Tire的构造参数从int变为String类型，或需要添加新的依赖时，调用链上的所有类（Bottom、Framework、Car）都必须逐一修改——工作量瞬间失控-11。

传统开发的核心弊端可概括为三点：

改需求要动源代码：替换一个依赖实现，必须修改所有调用它的代码；
无法便捷地做单元测试：依赖对象在类内部硬编码创建，难以用Mock对象替换；
依赖关系像蜘蛛网：要拿到一个对象A，可能需要先创建B、C、D等多个中间对象-6。

二、IoC（控制反转）：把“new”的权力上交

2.1 标准定义

IoC（Inversion of Control，控制反转） 是一种设计原则或架构思想，核心含义是：将对象的创建、管理权从应用程序代码转移给外部框架或容器-2。

简单来说：传统模式下，你主动new对象，控制权在你手里；IoC模式下，你把控制权“反转”交给容器，需要对象时被动接收即可。

2.2 生活化类比

理解IoC，可以用“去餐厅吃饭 vs 在家自己做饭”来类比-1：

场景	传统模式	IoC模式
类比	在家自己做饭	去餐厅吃饭
控制方式	你需要主动去超市买菜、洗菜、切菜、炒菜，全程自己控制	你只需点菜（声明需要什么），餐厅的厨师（IoC容器）负责采购、备菜、烹饪
紧耦合程度	如果菜场没货了，你直接受影响	你只关心菜单，不关心食材来源，与供应链完全解耦

2.3 IoC的价值

IoC解决的核心问题是解耦——遵循好莱坞原则： “Don‘t call us, we’ll call you.” （别找我们，我们会找你）-6。应用程序不再主动创建依赖对象，只需声明依赖，Spring容器会在合适时机把对象“送过来”。

三、DI（依赖注入）：让IoC落地生根

3.1 标准定义

DI（Dependency Injection，依赖注入） 是一种设计模式，是实现IoC原则的具体手段。它专门解决“如何将依赖对象传递给目标对象”的问题——由容器在创建对象时，自动把所需的依赖对象“注入”进去-2。

3.2 DI的三种注入方式

Spring提供了三种主要的依赖注入方式-6-45：

1. 构造器注入（Constructor Injection）—— 推荐使用

@Service
public class UserService {
    private final UserRepository userRepository;
    
    // 单个构造方法时，@Autowired可省略（Spring 4.3+）
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

优点：依赖不可变、强制非空、便于单元测试
缺点：无法解决循环依赖

2. Setter注入（Setter Injection）

@Service
public class UserService {
    private UserRepository userRepository;
    
    @Autowired
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

优点：支持可选依赖、可在运行时重新注入
缺点：依赖可变，对象状态不够安全

3. 字段注入（Field Injection）

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
}

优点：代码最简洁
缺点：难以进行单元测试，破坏了依赖的可见性（生产环境中不推荐使用）

四、IoC与DI的关系：一句话讲清区别

这是整个Spring面试中最常被问到、也最容易混淆的问题。先看结论：

维度	IoC（控制反转）	DI（依赖注入）
本质	设计原则、架构思想	具体的设计模式、实现技术
范畴	宽泛，涵盖程序流程控制	具体，聚焦对象依赖关系管理
关系	目标、目的	手段、方法
问题维度	回答“谁来控制”——控制权从代码交容器	回答“如何传递”——通过构造/Setter等方式传递依赖

一句话概括：IoC是“思想”，DI是“落地手段”。你问“为什么要做IoC”，答案是解耦；你问“IoC怎么做”，答案就是DI-2-。

面试官追问：没有DI，还能实现IoC吗？

可以。例如通过服务定位器模式（Service Locator）实现IoC——控制权已交予容器，但没有发生“注入”动作。但DI是当前最流行、最优雅的实现方式-2。

五、代码示例：从紧耦合到松耦合

5.1 配置阶段

在Spring Boot中，使用@Component（或@Service、@Repository、@Controller等派生注解）声明Bean，Spring容器会自动扫描并管理它们：

// 被依赖的类 - 交给Spring管理
@Repository
public class UserRepository {
    public String findById(Long id) {
        return "User from DB";
    }
}

// 业务类 - 通过构造器注入获取依赖
@Service
public class UserService {
    private final UserRepository userRepository;
    
    // 构造器注入（推荐方式）
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
    
    public String getUser(Long id) {
        return userRepository.findById(id);
    }
}

// 控制器类 - 注入UserService
@RestController
public class UserController {
    private final UserService userService;
    
    public UserController(UserService userService) {
        this.userService = userService;
    }
    
    @GetMapping("/user/{id}")
    public String getUser(@PathVariable Long id) {
        return userService.getUser(id);
    }
}

5.2 新旧实现方式对比

对比维度	传统实现	IoC + DI实现
依赖创建	在类内部用`new`手动创建	Spring容器自动创建并注入
代码耦合	高耦合，修改需改多处	低耦合，只需改配置
单元测试	困难，无法替换Mock对象	便捷，可传入Mock对象
代码复用	差，依赖关系散落在各处	好，依赖关系集中管理
改动成本	高，底层改动波及整个调用链	低，只需修改实现类

5.3 执行流程解读

启动阶段：Spring扫描所有带有@Component/@Service/@Controller注解的类，将其封装为BeanDefinition（Bean定义）；
实例化阶段：Spring根据BeanDefinition通过反射创建对象实例；
依赖注入阶段：Spring解析构造器参数（或@Autowired字段），从容器中获取对应类型的Bean，注入到目标对象中；
使用阶段：应用程序从容器中获取已组装好的Bean，直接使用。

整个过程，开发者只需关注业务逻辑，对象的创建和组装全部由Spring容器自动完成。

六、底层原理：反射与容器架构

6.1 技术依赖

Spring IoC容器的底层实现依赖两大技术：Java反射机制 + 工厂设计模式-31。

反射的作用：

动态读取类的构造器、字段、方法等信息；
运行时创建对象实例，无需在编译期确定类型；
解析注解（如@Autowired、@Service），识别哪些类需要被Spring管理。

6.2 核心容器架构

Spring IoC容器以两大核心接口为基础-31：

BeanFactory（基础接口）：

定义了IoC容器的最核心能力：getBean()、containsBean()等；
采用懒加载策略——只有调用getBean()时才创建Bean实例；
轻量但功能较少（不支持国际化、事件发布等）。

ApplicationContext（日常开发首选）：

继承自BeanFactory，是功能更完整的容器接口；
采用预加载策略——容器启动时就创建所有单例Bean；
支持国际化、事件发布、资源加载等企业级功能；
常见实现类：AnnotationConfigApplicationContext（注解配置）、ClassPathXmlApplicationContext（XML配置）。

6.3 核心流程

以注解配置为例，Spring IoC容器从启动到完成依赖注入，经历了以下核心步骤-31：

加载配置元数据：扫描包路径，识别@Component等注解，将类信息封装为BeanDefinition；
注册BeanDefinition：将BeanDefinition注册到注册表（BeanDefinitionRegistry）中，本质是一个Map<String, BeanDefinition>；
实例化Bean：通过反射调用构造器创建对象实例；
属性填充：解析依赖关系，通过反射将依赖注入到对象中；
初始化回调：执行@PostConstruct标注的初始化方法；
注册销毁回调：容器关闭时执行@PreDestroy等销毁逻辑。