早上起床，你想泡杯咖啡。你拿出咖啡机，往里面加水、放咖啡粉，按下开关。整个过程你自己动手，完全掌控——这就像传统编程里，一个类自己创建它需要的对象。
但假如你住进了智能公寓，只要说一句‘我要喝咖啡’，厨房自动运行程序，咖啡就送到了你面前。你不再关心谁烧的水、谁磨的豆子，只管提出需求。这种‘把控制权交出去’的做法，就是控制反转（Inversion of Control，简称 IoC）。
控制反转：别再自己 new 对象了
在写代码时，我们常看到这样的场景：
class UserService {
private UserRepository userRepository = new UserRepository();
public User findUser(int id) {
return userRepository.findById(id);
}
}这里 UserService 自己创建了 UserRepository。一旦数据源变了，比如要换成 MongoDB，就得改这个类。耦合太紧，维护起来头疼。
控制反转的意思是：别自己 new 了，让别人帮你安排。谁？通常是容器。你只负责声明‘我需要什么’，具体谁来提供，由外部决定。
依赖注入：把需要的东西‘塞’进来
怎么实现控制反转？最常见的办法就是依赖注入（Dependency Injection，简称 DI）。名字听着高大上，其实就是把对象传进去，而不是自己创建。
还是上面的例子，改写一下：
class UserService {
private UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public User findUser(int id) {
return userRepository.findById(id);
}
}现在 UserService 不再自己 new UserRepository，而是通过构造函数接收一个实例。谁传？可能是框架，也可能是另一个工厂类。这样一来，换数据库就不需要动业务逻辑，只要换个实现传进去就行。
就像你点外卖，不需要知道饭是谁做的、锅有没有洗，只要拿到餐盒，能吃就行。你依赖的是‘一顿饭’，而不是‘某个厨师+某口锅’。
三种常见的注入方式
除了构造函数注入，还有两种常见写法：
设值注入（Setter Injection）：
class UserService {
private UserRepository userRepository;
public void setUserRepository(UserRepository userRepository) {
this.userRepository = userRepository;
}
}接口注入： 用得少一些，一般是定义一个接口，包含设置依赖的方法，类实现它。
现代框架如 Spring，默认推荐构造函数注入，因为更利于不可变性和测试。
实际开发中的好处
项目做大了，类之间关系复杂。如果没有 DI，改一个底层模块，可能牵出十几个要重写的类。
用了依赖注入后，各组件只依赖抽象，不依赖具体实现。测试时还能轻松替换模拟对象（Mock），比如把真实的邮件服务换成一个记录日志的假服务。
Spring Boot 启动类上那个 @Autowired，本质上就是告诉容器：‘这儿需要个对象，你看着办，合适就塞进来’。背后整套机制，都是基于 IoC 容器在运作。
刚开始接触时会觉得‘绕’，明明可以直接 new 却非要搞一堆配置。可一旦项目需要频繁扩展、多人协作，这种‘提前解耦’的代价就显得非常值得。
技术不是为了炫技，而是为了解决真实问题。依赖注入和控制反转，解决的就是‘变化太快，代码跟不上’的日常痛点。