IoC核心是将依赖关系的决策权从类内部移交容器，而非仅转移对象创建；DI是其落地方式，通过构造器、Setter或字段注入实现声明式依赖与外部履约。
控制反转（IoC）的核心原理，不是“把创建对象的代码搬到框架里”这么表面，而是把“谁来决定依赖怎么来”这个权力，从类内部彻底移交出去。关键不在“谁 new 对象”，而在“谁掌握依赖关系的决策权”。
控制权到底反转了什么
传统写法中，一个类自己决定依赖怎么来：
- UserService 里直接 new UserRepository() → 它决定了用哪个实现、什么时候创建、生命周期多长；
- 如果要换数据库，得改 UserService 的源码；
- 单元测试时没法替换成 Mock 对象，因为依赖是硬编码的。
IoC 反转的，正是这个“决定权”。容器不代替你写业务逻辑，而是接管“依赖从哪来、用谁、何时提供”的判断——类只声明“我需要 UserRepository”，至于具体给它哪个实例、是新造一个还是复用旧的、是否线程安全，全由外部统一配置和管理。
依赖注入（DI）是 IoC 最落地的实现方式
DI 不是一种技术堆砌，而是一种契约：类通过构造函数、Setter 或字段，明确表达“我依赖什么接口”，把初始化的责任让渡出去。容器按需履约：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 构造注入 → 实例化时必须给齐依赖，对象一建好就完整可用；
- Setter 注入 → 允许后期动态替换，适合可选或可变依赖；
- 字段注入（如 @Autowired）→ 简洁但隐藏依赖，不利于测试和重构。
真正起作用的，是这种“声明式依赖 + 外部履约”的协作模式，而不是某一行注解本身。
反转之后带来的实际变化
IoC 不是为炫技，它让系统结构变得更可控：
- 解耦发生在编译期：UserService 编译时只依赖 UserRepository 接口，不绑定任何实现类；
- 配置决定行为：同一个 UserService，在开发环境注入内存版 Repository，生产环境注入 MySQL 版，代码零修改；
- 生命周期由容器统管：单例 Bean 全局复用，作用域 Bean 按请求隔离，这些规则集中定义，不散落在各处 new 语句里。
别把 IoC 理解成“Spring 才有的功能”
本质是一种设计原则，Spring、.NET Core、Guice 都只是实现者。哪怕手写一个简单工厂+Map 缓存，只要做到“类不主动找依赖、只被动接收”，就已经在实践 IoC。区别只在于：容器是否帮你做了自动装配、循环依赖检测、AOP 织入等增强能力。
