本文目录导读：
- 文章导读目录
- 什么是依赖注入？——从“硬编码”到“解耦”的演进
- 为什么需要依赖注入？——降低耦合、提高可测试性
- Java中实现依赖注入的三种主流方式
- 从零手写一个简易的依赖注入容器（案例核心源码）
- 主流框架对比：Spring vs Guice vs 手写
- QA问答：依赖注入常见误区与最佳实践
- 总结与延伸：依赖注入在企业级开发中的真正价值
文章导读目录
- 什么是依赖注入？——从“硬编码”到“解耦”的演进
- 为什么需要依赖注入？——降低耦合、提高可测试性
- Java中实现依赖注入的三种主流方式
- 1 构造器注入（Constructor Injection）
- 2 Setter注入（Setter Injection）
- 3 接口注入（Interface Injection）
- 从零手写一个简易的依赖注入容器（案例源码）
- 1 定义注解
- 2 创建容器类
- 3 测试运行
- 主流框架对比：Spring vs Guice vs 手写
- QA问答：依赖注入常见误区与最佳实践
- 总结与延伸：依赖注入在企业级开发中的真正价值
什么是依赖注入？——从“硬编码”到“解耦”的演进
很多初学Java的朋友都会遇到这样的场景：在UserService中，直接new一个UserDao对象。
public class UserService {
private UserDao userDao = new UserDao(); // 强耦合
public void save(User user) {
userDao.insert(user);
}
}
这种做法看似简单，但一旦UserDao需要换成MySqlUserDao或MockUserDao，就必须修改UserService的源代码。依赖注入（Dependency Injection，DI）的核心思想是：对象不自己创建依赖，而是由外部容器在运行时传入依赖，这样，UserService只需要声明“我需要一个UserDao”，而创建和选择实现类的逻辑，交给上层容器（如Spring IoC容器）完成。
关键词聚焦：Java案例怎么实现依赖注入？我们先从“为什么”开始，再深入到“怎么做”。
为什么需要依赖注入？——降低耦合、提高可测试性
| 问题场景 | 传统写法 | 使用DI后 |
|---|---|---|
| 单元测试 | 必须同时加载真实数据库 | 可以轻松注入Mock对象 |
| 替换实现 | 修改大量new代码 | 修改配置或注入类型即可 |
| 代码复用 | 接口与实现绑定死 | 面向接口编程，松散耦合 |
典型例子：假设你的项目从MySQL迁移到PostgreSQL，如果没有DI，你需要修改所有new UserDaoImpl()的代码；而有了DI，只需改动容器中的bean配置（或一个注解），所有使用UserDao的地方自动切换。
Java中实现依赖注入的三种主流方式
1 构造器注入（Constructor Injection）
这是最推荐的方式,被注入的依赖通过构造函数传入。
public class OrderService {
private final PaymentGateway paymentGateway;
// 构造器注入：外部通过参数传入依赖
public OrderService(PaymentGateway paymentGateway) {
this.paymentGateway = paymentGateway;
}
}
2 Setter注入（Setter Injection）
通过setter方法注入依赖,适合可选依赖或需要动态替换的场景。
public class NotificationService {
private MessageSender sender;
public void setMessageSender(MessageSender sender) {
this.sender = sender;
}
}
3 接口注入（Interface Injection）
定义一个注入接口，让容器通过该接口传入依赖，这种方式在现代框架中使用较少,已被构造器注入和Setter注入取代。
public interface MessageSenderAware {
void setMessageSender(MessageSender sender);
}
从零手写一个简易的依赖注入容器（案例核心源码）
为了让读者真正理解“Java案例怎么实现依赖注入”，这里我们手写一个微型IoC容器,它依赖Java注解和反射机制。
1 定义注解
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface MyComponent {}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface MyAutowired {}
2 创建容器类
import java.io.File;
import java.lang.reflect.Field;
import java.net.URL;
import java.util.*;
public class MiniIoCContainer {
private final Map<Class<?>, Object> beans = new HashMap<>();
// 从包路径扫描所有带@MyComponent的类
public void scan(String basePackage) throws Exception {
String path = basePackage.replace('.', '/');
Enumeration<URL> resources = Thread.currentThread()
.getContextClassLoader().getResources(path);
while (resources.hasMoreElements()) {
File dir = new File(resources.nextElement().getFile());
for (File file : dir.listFiles()) {
if (file.getName().endsWith(".class")) {
String className = basePackage + "." + file.getName().replace(".class", "");
Class<?> clazz = Class.forName(className);
if (clazz.isAnnotationPresent(MyComponent.class)) {
Object instance = clazz.getDeclaredConstructor().newInstance();
beans.put(clazz, instance);
}
}
}
}
// 执行依赖注入
for (Object bean : beans.values()) {
injectDependencies(bean);
}
}
private void injectDependencies(Object bean) throws Exception {
Field[] fields = bean.getClass().getDeclaredFields();
for (Field field : fields) {
if (field.isAnnotationPresent(MyAutowired.class)) {
Object dependency = beans.get(field.getType());
if (dependency == null) {
throw new RuntimeException("未找到依赖: " + field.getType());
}
field.setAccessible(true);
field.set(bean, dependency);
}
}
}
public <T> T getBean(Class<T> clazz) {
return clazz.cast(beans.get(clazz));
}
}
3 测试运行
public class MainTest {
public static void main(String[] args) throws Exception {
MiniIoCContainer container = new MiniIoCContainer();
container.scan("com.example.ioc");
UserService service = container.getBean(UserService.class);
service.save(new User("小明"));
}
}
// 标记为组件
@MyComponent
public class UserDaoImpl implements UserDao {
public void insert(User user) {
System.out.println("保存用户: " + user.getName());
}
}
@MyComponent
public class UserService {
@MyAutowired
private UserDao userDao;
public void save(User user) {
userDao.insert(user);
}
}
运行结果输出： 保存用户: 小明
这个案例演示了最简版本的手写DI容器：扫描包、实例化Bean、通过注解完成字段注入，虽然简单,但包含了依赖注入的核心逻辑。
主流框架对比：Spring vs Guice vs 手写
| 特性 | Spring IoC | Google Guice | 手写容器（如上） |
|---|---|---|---|
| 注解支持 | @Component, @Autowired等 | @Inject, @Singleton | @MyComponent, @MyAutowired |
| 生命周期管理 | 完整（单例、原型、作用域） | 简单 | 无 |
| AOP集成 | 天然支持 | 需额外代码 | 不支持 |
| 学习成本 | 中等（但生态庞大） | 低 | 高（需理解反射） |
选择建议：对于真实企业项目，优先用Spring；对于微型工具或学习原理,手写容器是个很好的练手方式。
QA问答：依赖注入常见误区与最佳实践
Q1：依赖注入是不是只能通过Spring实现？ A：不是，依赖注入是一种设计思想，Spring只是最流行的实现，你也可以用纯Java代码、Guice或自己写容器来实现。
Q2：字段注入（@Autowired）为什么不推荐？ A：使用字段注入会使类难以进行单元测试（无法通过构造器传入Mock），而且容易产生循环依赖,官方推荐使用构造器注入。
Q3：手写容器和Spring容器有什么本质区别？ A：手写容器往往只执行最基本的“查找-实例化-注入”三个步骤，Spring容器则包含Bean生命周期回调（@PostConstruct、@PreDestroy）、作用域代理、懒加载、远程配置等一系列高级功能。
Q4：依赖注入会不会影响性能？ A：影响主要在启动阶段（反射扫描和创建Bean），运行时几乎没有额外开销，现代框架通过字节码增强和缓存机制,性能损耗可以忽略不计。
Q5：什么情况下应该放弃依赖注入？ A：在极简单的脚本工具（只有一个类）或性能极度敏感的嵌入式环境（如实时操作系统），直接new反而更清晰，但大多数企业级Web应用、微服务、桌面应用,依赖注入都能带来明显的维护收益。
总结与延伸：依赖注入在企业级开发中的真正价值
通过本文的详细Java案例，我们从最原始的new代码，演进到自定义注解扫描和注入容器，完整演示了“Java案例怎么实现依赖注入”的每一个环节,依赖注入的核心价值在于：
- 解耦：调用者不依赖具体实现,只依赖抽象接口。
- 可测试性：可轻松替换为Mock对象进行单元测试。
- 灵活性：通过配置文件或注解调整行为,无需改动业务代码。
如果你想进一步深入,可以尝试：
- 在容器中添加单例/原型作用域支持
- 实现循环依赖检测与解决
- 整合AOP代理（基于JDK动态代理或CGLib）
记住：依赖注入不是框架的专利，而是一种让代码更健壮、更容易维护的设计模式，掌握它的原理,你就能在任何项目中活用它。
