在 Spring 中，依赖注入的方式有多种选择。下面我们来逐一分析它们的特点、适用场景和注意事项：
1. 构造函数注入
构造函数注入要求在对象创建时提供所有依赖。这种方式确保依赖在对象创建后不可变，特别适合必须强制存在的依赖。所有依赖在对象实例化时即被注入，保证了依赖的一致性。
代码示例：
java
public class Car {
private final Engine engine;
public Car(Engine engine) {
this.engine = engine;
}
}优点：
- 确保依赖不可变，提升代码稳定性。
- 更符合单一职责原则，有利于单元测试，因为构造函数明确列出了依赖项。
缺点：
- 当依赖数量过多时，构造函数会显得过于复杂。
2. Setter 注入
Setter 注入允许在对象实例化后进行依赖的设置。相比构造函数注入，它更灵活，允许可选依赖。
代码示例：
java
public class Car {
private Engine engine;
public void setEngine(Engine engine) {
this.engine = engine;
}
}优点：
- 更加灵活，允许在对象创建之后再注入依赖。
- 可以处理部分依赖可能为空的情况，适合有默认依赖的场景。
缺点：
- 可能导致对象在使用前未完成依赖的设置，增加了潜在风险。
3. 字段注入
字段注入是通过 @Autowired 直接在属性上进行注入，Spring 会自动完成依赖的注入。这种方式简化了代码，但增加了依赖管理的复杂性。
代码示例：
java
public class Car {
@Autowired
private Engine engine;
}优点：
- 代码简洁，不需要编写构造函数或 setter 方法。
- 非常适合简单项目或快速开发场景。
缺点：
- 依赖隐式注入，不易发现未初始化的属性。
- 对单元测试不友好，需要使用反射进行依赖注入，增加测试复杂度。
4. 接口注入
接口注入通过定义特定接口，使实现类实现依赖的注入。这种方式在 Spring 项目中较少使用，但在一些严格控制的依赖关系中非常有效。
代码示例：
java
public interface EngineAware {
void setEngine(Engine engine);
}
public class Car implements EngineAware {
private Engine engine;
@Override
public void setEngine(Engine engine) {
this.engine = engine;
}
}优点：
- 清晰的依赖关系，强制依赖约束。
- 更加灵活，能够在运行时动态注入依赖。
缺点：
- 增加了接口的复杂性，通常不常用。
5. 工厂方法注入
通过 Spring 的 @Bean 注解，可以在工厂方法中生成 Bean，并进行复杂的依赖注入处理，适用于需要自定义创建逻辑的场景。
代码示例：
java
@Bean
public Car car() {
return new Car(engine());
}
@Bean
public Engine engine() {
return new Engine();
}优点：
- 更灵活，允许复杂依赖的创建和配置。
- 适合处理多步骤初始化的复杂依赖。
缺点：
- 代码较为复杂，适合高级场景，不适合简单项目。
6. @Primary 和 @Qualifier 注解
当有多个相同类型的 Bean 时，Spring 提供了 @Primary 和 @Qualifier 注解来决定注入哪个 Bean。@Primary 标记默认注入的 Bean，@Qualifier 用来指定具体的 Bean。
代码示例：
java
@Component
@Qualifier("dieselEngine")
public class DieselEngine implements Engine {}
@Component
@Primary
public class ElectricEngine implements Engine {}
@Autowired
@Qualifier("dieselEngine")
private Engine engine;优点：
- 能精确选择 Bean，特别是在有多个相同类型的 Bean 时。
- 提供了更加明确的控制，避免错误的 Bean 注入。
缺点：
- 增加了配置的复杂性，适合有多个候选 Bean 的项目。
7. 环境配置条件注入
通过 @Conditional 注解，Spring 可以根据不同的条件注入依赖。例如，根据不同的环境配置文件（如 application-dev.yml 和 application-prod.yml），来决定注入哪个 Bean。
代码示例：
java
@ConditionalOnProperty(name = "app.env", havingValue = "dev")
@Bean
public DataSource devDataSource() {
return new HikariDataSource();
}
@ConditionalOnProperty(name = "app.env", havingValue = "prod")
@Bean
public DataSource prodDataSource() {
return new DruidDataSource();
}优点：
- 允许根据环境动态注入 Bean，适合大型应用的多环境部署。
- 减少了不必要的 Bean 加载，提升了性能。
缺点：
- 需要依赖配置文件，增加了应用的复杂度。
依赖注入方式的对比
| 特性 | 构造函数注入 | Setter 注入 | 字段注入 | 接口注入 | 工厂方法注入 | @Primary 与 @Qualifier |
环境配置注入 |
|---|---|---|---|---|---|---|---|
| 依赖注入时机 | 对象创建时 | 对象创建后 | 框架自动完成 | 接口回调实现 | 工厂方法调用 | 明确指定注入 Bean | 动态条件 |
| 代码简洁性 | 较为复杂 | 中等 | 最简洁 | 较复杂 | 较复杂 | 中等 | 中等 |
| 灵活性 | 较为固定 | 灵活 | 灵活 | 灵活 | 非常灵活 | 灵活 | 高度灵活 |
| 可维护性 | 高 | 中等 | 较低 | 中等 | 高 | 高 | 高 |
| 测试友好性 | 高 | 中等 | 低 | 中等 | 高 | 高 | 高 |
结论
Spring 提供了多种依赖注入方式，每种方式都有其适用场景。构造函数注入最为稳健，但当需要灵活性时，Setter 注入和字段注入更为适合。工厂方法和条件注入适合更复杂的场景，而 @Qualifier 和 @Primary 则用于处理多实现 Bean。根据项目需求选择合适的注入方式，才能在保持代码清晰的同时，提升可维护性和可扩展性。
