Spring Boot依赖注入应规避字段注入，优先使用构造器注入以保障可测性、不可变性和可读性；setter注入仅适用于可选依赖；prototype Bean需将运行时参数纳入构造器；减少@SpringBootTest滥用，改用分层测试。
Spring Boot 中依赖注入的常见反模式，核心问题不在“能不能用”，而在于“用在哪、为什么用、后续怎么维护”。避开这些坑的关键，是理解每种方式对可测性、可变性、可读性和容器解耦的影响。下面从四个最典型、最易踩的点展开。
字段注入（@Autowired + private 字段）应全面规避
它看似省事，但会带来三重隐性成本：
- 无法声明 final，对象创建后依赖可能被意外修改或设为 null
- 单元测试必须依赖 Spring 上下文（如
@SpringBootTest）或反射赋值，mock 成本高、可读性差 - 类的真实依赖不体现在构造逻辑中，新人阅读时难以一眼识别“这个类到底需要什么才能工作”
✅ 正确做法：全部改用构造器注入。Spring 4.3+ 单构造器无需 @Autowired 注解，且天然支持 final 字段：
private final PaymentService paymentService;
private final InventoryService inventoryService;
public OrderService(PaymentService paymentService, InventoryService inventoryService) {
this.paymentService = paymentService;
this.inventoryService = inventoryService;
}
}
Setter 注入仅用于真正可选或需运行时重置的依赖
它不是构造器注入的“备选方案”，而是有明确适用边界的补充手段：
- 只在依赖确实允许为 null 或后续可能被替换（如策略切换、监听器注册）时使用
- 必须显式标注
@Autowired(required = false)，否则 Spring 启动失败时提示模糊 - 避免与 Lombok 的
@RequiredArgsConstructor混用——Lombok 不会为 setter 生成初始化逻辑
⚠️ 常见误用：把数据库 Repository、外部 API 客户端等核心依赖写成 setter 注入，导致对象处于“半初始化”状态。
原型（Prototype）Bean 混用字段注入导致不可测试
当一个 Bean 是 @Scope("prototype") 且携带运行时参数（如 Options options）时，字段注入会让它彻底脱离测试控制：
- 无法在单元测试中直接
new MyAdapter(options, mockService) - 被迫用
ReflectionTestUtils.setField()或写测试专用构造器，违背单一职责
✅ 解法：把所有依赖（含运行时参数）都作为构造器参数，让 Spring 容器和测试代码使用同一套实例化路径：
@Scope("prototype")public class DataProcessor {
private final DataSource dataSource;
private final ProcessingOptions options;
public DataProcessor(DataSource dataSource, ProcessingOptions options) {
this.dataSource = dataSource;
this.options = options;
}
}
测试中滥用 @SpringBootTest 加载全量上下文
这不是注入方式本身的问题，但常因依赖注入设计不当而加剧：
- 字段注入的类难以单独实例化 → 开发者只能退回到
@SpringBootTest，拖慢测试速度、掩盖真实耦合 - 正确注入设计后，90% 的业务逻辑测试应使用
@MockitoTest或纯 new + mock，不启动容器
✅ 替代方案按场景选择：
- Controller 测试 →
@WebMvcTest - JPA 层测试 →
@DataJpaTest - 单个 Service 单元测试 → 不加任何 Spring 测试注解，手动构造 +
@Mock
