从一个生活场景说起
你去咖啡店点单，说要一杯美式咖啡。服务员没问你是用哪种咖啡机做的，也没问咖啡豆是哪个产地的，直接给你端上来。背后的咖啡制作流程被“隐藏”了，你只关心结果——喝到咖啡。
这其实和编程里的“控制反转”（Inversion of Control，简称 IoC）有点像。以前是你主动创建对象、控制流程，现在变成了“别人”帮你准备好，你要的东西自动送上门。
什么是控制反转？
在写代码时，传统做法是 A 类需要 B 类的功能，就自己 new 一个 B 的实例出来。A 类牢牢掌控着 B 的创建过程。
比如：
class UserService {
private UserRepository userRepository = new UserRepository();
public User getUserById(int id) {
return userRepository.findById(id);
}
}这里 UserService 自己负责创建 UserRepository，耦合度高。如果哪天想换成 MongoDB 实现，就得改 UserService 的代码。
控制反转就是把这种“谁用谁创建”的逻辑翻转过来。不是由使用者创建依赖，而是由外部统一管理并注入进去。谁需要，就给谁塞一个现成的对象。
依赖注入是实现控制反转的方式
依赖注入（Dependency Injection，简称 DI）就是把对象所需的依赖“塞”进来，而不是在内部自己 new。最常见的做法是通过构造函数传入。
还是上面的例子，改造一下：
class UserService {
private UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public User getUserById(int id) {
return userRepository.findById(id);
}
}现在 UserRepository 不再由 UserService 内部创建，而是在外面创建好，通过构造函数传进来。这样，换数据源时只需要传不同的实现，UserService 根本不用动。
实际开发中的好处
假设你在做一个电商系统，订单服务需要支付功能。如果是自己 new 支付类，测试时想模拟“支付成功”或“支付失败”就很麻烦，因为你得真调接口。
用了依赖注入后，测试时可以传一个“假”的支付对象，专门用来模拟各种情况，代码不变，行为可调。
很多框架，比如 Spring，就是靠这套机制运作的。你写个类，加个注解，框架自动帮你把依赖配好，启动时全都安排妥当。
简单理解两者关系
控制反转是个思想，意思是“别啥都自己动手，交给别人管”。依赖注入是实现这个思想的具体手段之一，就像“外包”是公司降低成本的一种方式。
你可以把整个容器想象成一个大管家，所有对象都在它那里登记过。谁需要什么，它就自动装配，不用你自己到处找。
刚开始接触可能觉得绕，但用多了就会发现，代码变得更干净，更容易测试，也更容易维护。就像你不需要知道咖啡怎么煮的，只要能喝到就行。