在 Spring 应用中，若将 AccountValidator 等有状态对象通过 new 实例化，会导致其依赖不可见、难以测试和管理；正确做法是将其声明为 Spring 管理的 Bean（如 prototype 作用域），并通过 ObjectProvider 按需获取，兼顾可测性、解耦性与生命周期可控性。
在 spring 应用中，若将 `accountvalidator` 等有状态对象通过 `new` 实例化，会导致其依赖不可见、难以测试和管理；正确做法是将其声明为 spring 管理的 bean（如 prototype 作用域），并通过 `objectprovider` 按需获取，兼顾可测性、解耦性与生命周期可控性。
在依赖注入（DI）实践中，一个常见但易被忽视的设计陷阱是：将有状态对象（如 AccountValidator）在业务类中直接 new 实例化。这看似简洁，实则破坏了 DI 的核心原则——显式声明依赖、统一管理生命周期、保障可测试性。例如，原始代码中 MyService 通过 new AccountValidator(account) 创建验证器，导致该依赖对 Spring 容器“不可见”，既无法被 AOP 增强（如日志、事务），也使单元测试必须耦合 AccountValidator 的具体实现（或被迫使用 @MockBean 干扰容器上下文）。
✅ 推荐方案：声明为 Prototype Bean + ObjectProvider 注入
Spring 支持将有状态、非线程安全的对象声明为 @Scope(SCOPE_PROTOTYPE) Bean。每次请求时容器都会创建新实例，确保状态隔离；而通过 ObjectProvider
@Component
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class AccountValidator {
private final Account account;
// 构造注入依赖（如规则引擎、外部服务等）
public AccountValidator(Account account, ValidationRuleService ruleService) {
this.account = account;
// ... 初始化逻辑
}
public boolean isValid() {
return /* 验证逻辑 */;
}
}在 MyService 中，不再 new，而是通过 ObjectProvider
@Service
public class MyService {
private final AuxiliaryService auxiliaryService;
private final ObjectProvider<AccountValidator> validatorProvider;
public MyService(AuxiliaryService auxiliaryService,
ObjectProvider<AccountValidator> validatorProvider) {
this.auxiliaryService = auxiliaryService;
this.validatorProvider = validatorProvider;
}
public boolean isAccountValid(Account account) {
// 每次调用都获得一个全新、独立的 AccountValidator 实例
AccountValidator validator = validatorProvider.getObject();
boolean isValid = validator.isValid(); // 注意：account 已在构造时传入
if (isValid) {
auxiliaryService.openAccount(account);
}
return isValid;
}
}⚠️ 关键细节：AccountValidator 的构造参数（如 Account）不能由 Spring 自动注入（因 Account 是运行时动态数据）。此时应采用 工厂模式 + 构造参数传递 或 Builder 模式。但更推荐将 Account 作为 isValid() 方法参数（无状态设计），仅在必要时才将 Account 作为构造参数并配合 ObjectProvider 的 getObject(account) 重载（需自定义 FactoryBean 或 @Lookup 方法，Spring 5.1+ 支持 ObjectProvider 的泛型参数传递，但需手动实现）。
? 为什么优于工厂类方案？
- 减少样板代码：无需为每个验证器编写 AccountValidatorFactory，避免“工厂爆炸”；
- 容器统一治理：AccountValidator 可享受 @Autowired、@PostConstruct、AOP 代理等 Spring 特性；
- 测试友好：单元测试中可轻松 @MockBean AccountValidator 或 @SpyBean，无需修改 MyService 构造逻辑；
- 语义清晰：ObjectProvider 明确表达了“每次需要一个新实例”的意图，比隐式 new 更具可读性与契约性。
? 总结建议
- ✅ 优先将有状态对象声明为 @Scope("prototype") Bean，而非 new 或工厂；
- ✅ 使用 ObjectProvider
注入 ，而非 T 直接注入（后者会注入单例，违背原型语义）； - ✅ 若验证器需运行时参数（如 Account），优先重构为方法参数（无状态设计）；若必须构造时传入，可结合 @Lookup 方法或自定义 FactoryBean；
- ❌ 避免在业务类中 new 第三方/领域对象，这本质上是“DI 抗拒”，会侵蚀架构的可维护性与可测性。
通过这一实践，MyService 的依赖图完全透明，测试可精准模拟行为，扩展时亦能无缝集成切面、指标、熔断等横切关注点——这才是依赖注入的真正价值所在。
