控制反转（IoC）是将对象创建与依赖管理权移交外部容器的设计思想，依赖注入（DI）是其实现手段；DI含构造函数、Setter、接口三种注入方式，其中接口注入已基本弃用；IoC还涵盖依赖查找、上下文绑定、事件驱动等维度；依赖倒置原则（DIP）是其理论基础；IoC容器核心工作流为注册—解析—注入。
一、控制反转是设计思想，依赖注入是实现手段
控制反转（IoC）并非具体技术，而是一种高层设计原则，其本质在于将对象的创建权和依赖关系的管理权从程序内部移交至外部容器。这种“反转”体现在执行流程控制权的转移：原本由类自身主动创建依赖，现在变为被动接收由容器提供的依赖实例。依赖注入（DI）则是落实这一思想的具体技术路径，它定义了依赖如何被传递给目标对象。
1、控制反转关注“谁来控制”，强调控制权归属的变更；
2、依赖注入关注“如何传递”，聚焦于依赖项注入的具体机制；
3、没有IoC，DI失去目标语境；没有DI，IoC缺乏可落地的技术支撑。
二、依赖注入的三种主流注入方式
依赖注入通过不同载体将依赖对象送入被依赖方，每种方式对应不同的生命周期约束与使用场景。构造函数注入确保依赖不可为空，Setter注入支持运行时动态替换，接口注入则通过契约约定注入行为，但实践中已较少采用。
1、构造函数注入：在对象初始化时通过参数传入依赖，适用于强制依赖且不可变的场景；
2、Setter方法注入：通过公开的setter方法设置依赖，适用于可选依赖或需后期重置的场景；
3、接口注入：被注入类实现特定接口，容器调用接口方法完成注入，需额外定义注入契约，侵入性强，现已基本被弃用。
三、控制反转涵盖更广的实现维度
依赖注入仅是控制反转的一种实现形式，IoC容器还可通过依赖查找（Service Locator）、上下文绑定、事件驱动等方式达成控制权移交。这些方式不依赖“注入”动作本身，而是通过主动查询或响应式机制获取依赖，从而扩展了IoC的应用边界。
1、依赖查找：对象向容器主动请求所需服务，解耦程度低于DI，因对象仍持有容器引用；
2、上下文绑定：基于运行时上下文（如HTTP请求、事务边界）动态绑定依赖，适用于多租户或隔离环境下的依赖隔离；
3、事件驱动注入：依赖在特定事件触发后才被创建并注入，适用于延迟加载或条件化依赖场景。
四、依赖倒置原则（DIP）是IoC/DI的理论基础
依赖倒置原则属于SOLID设计原则之一，它规定高层模块不应依赖低层模块，二者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。该原则为IoC提供了架构层面的合理性支撑，使接口与实现分离成为可能，进而让容器能自由替换具体实现而不影响调用方。
1、若未遵循DIP，IoC容器无法在不修改源码的前提下切换实现类；
2、DIP要求定义清晰的接口契约，这是注册阶段（Register）能够成立的前提；
3、DIP的实践结果直接决定DI能否真正达成松耦合，而非仅表面解耦。
五、注册—解析—注入是IoC容器的核心工作流
无论采用何种注入方式，现代IoC容器均围绕三个原子操作展开：注册声明抽象与实现的映射关系，解析根据类型信息递归构建对象图，注入将已解析实例按约定方式装配到目标对象中。该流程屏蔽了反射、生命周期管理、作用域控制等底层复杂性。
1、注册阶段需明确接口与具体类的绑定，例如 container.Register
2、解析阶段自动处理循环依赖、泛型类型推导及嵌套依赖链；
3、注入阶段依据构造函数参数签名或属性标记，将解析所得实例精准送达目标位置。
