控制反转（IoC）是高层设计思想，指将对象控制权从代码移交容器；依赖注入（DI）是其实现手段，指通过构造、Setter等方式由容器注入依赖。IoC回答“谁控制”，DI回答“如何传”，二者维度不同，不可互换。
如果您在学习Spring或面向对象设计时遇到“控制反转”和“依赖注入”两个术语，却难以区分其本质差异，则可能是由于二者常被混用，但实际处于不同抽象层级。以下是厘清这一区别的具体说明：
一、控制反转（IoC）是一种设计思想
控制反转描述的是程序执行控制权的转移过程，它不特指某段代码或某种技术，而是一种高层级的设计原则。其核心在于将对象的生命周期管理、依赖关系建立等控制行为，从应用程序内部移交给外部容器或框架来承担。
1、在传统编程中，类A需要使用类B时，通常在A内部直接通过new B()创建B的实例；
2、此时A完全掌控B的创建时机、方式与生命周期，属于“正转”；
3、当引入IoC后，A不再负责创建B，而是由外部容器（如Spring ApplicationContext）统一管理B的实例化与供给；
4、A仅声明对B的依赖，具体何时创建、如何复用、是否单例等均由容器决定；
5、这种控制权从A向容器的移交，即为“反转”——控制权由程序员代码转向框架容器。
二、依赖注入（DI）是实现IoC的具体手段
依赖注入并非独立存在的概念，而是IoC思想落地时最常用、最典型的实现机制。它聚焦于“如何把依赖对象送入目标对象”，强调的是依赖传递的方式与路径，而非控制权归属本身。
1、构造函数注入：目标类通过构造参数接收依赖，如public UserService(UserRepository repo)；
2、Setter方法注入：依赖通过公共setter方法设置，如setUserRepository(UserRepository repo)；
3、接口注入：目标类实现特定接口，由外部调用接口方法注入依赖（实践中极少使用）；
4、无论采用哪种形式，DI本身并不改变控制权归属，但它使IoC得以在代码中可操作、可配置、可测试；
5、没有DI，IoC可能通过依赖查找（Service Locator）等方式实现，但DI已成为事实标准。
三、二者不可互换的根本原因
IoC与DI分属不同维度：IoC回答“谁来控制”，DI回答“怎么传递”。混淆二者往往源于Spring文档与日常开发中将DI作为IoC的默认表达，导致概念边界模糊。
1、一个系统可以存在IoC但不使用DI，例如通过JNDI查找服务，控制权已交予容器，但未发生“注入”动作；
2、DI必须依附于某种控制权上收机制，否则只是普通参数传值，无法构成IoC；
