Setter注入不支持动态切换依赖，仅在Spring容器初始化Bean时一次性赋值；动态切换需结合策略模式、条件注解、FactoryBean或配置中心监听等机制实现。
Setter注入本身不支持“动态切换依赖”这种运行时行为，它只是在Spring容器初始化Bean时，通过调用setter方法完成一次性的依赖赋值。所谓“动态切换”，实际需要的是运行时根据条件选择不同实现类并生效，这超出了Setter注入的设计范畴，需结合其他机制协同实现。
Setter注入的本质限制
Setter方法注入发生在Bean实例化之后、初始化之前（即postProcessBeforeInitialization阶段），属于一次性操作。一旦注入完成，字段值就被固定，除非手动再次调用该setter——但这已脱离Spring容器管理，容易引发状态不一致或线程安全问题。
- 无法自动响应配置变更、环境切换或业务规则变化
- 不适用于多例（prototype）Bean的每次获取都需不同依赖的场景
- 若强行在业务代码中反复调用setter，会破坏依赖不可变性与测试可预测性
真正支持动态切换的常用方案
要实现依赖的动态切换，应放弃单纯依赖Setter注入，转而采用以下更合理的方式：
-
策略模式 + ApplicationContext.getBean()：定义统一接口，多个实现类标注
@Service("strategyA")、@Service("strategyB")，运行时按key从容器中获取对应Bean - @ConditionalOnProperty 或 @Profile 配合构造注入：在启动阶段根据配置项或激活环境决定加载哪个Bean，适合静态切换
- 自定义FactoryBean 或 Lookup Method Injection：对prototype Bean，可通过抽象方法让Spring每次返回新实例，间接实现“动态”效果
-
结合Spring Cloud Config / Nacos / Apollo 的监听回调：监听配置变更后，触发重新获取或刷新某个代理Bean（如用
@RefreshScope修饰）
Setter注入仍可参与的辅助角色
虽然不能直接用于动态切换，但Setter注入在某些组合场景下仍有价值：
- 为策略上下文对象注入一个可变的“当前策略引用”，该引用由外部逻辑（如路由服务）负责更新
- 配合
@Lazy和@Scope("prototype")，延迟获取具体实现，再通过setter设入目标组件（需确保线程安全） - 在单元测试中，便于用
mock对象覆盖真实依赖，比构造注入更易替换
不推荐的“伪动态”写法示例
以下代码看似能切换，实则危险：
❌ 错误示范（破坏容器契约）@Service
public class OrderProcessor {
private PaymentService paymentService;
@Autowired
public void setPaymentService(PaymentService paymentService) {
this.paymentService = paymentService;
}
// 外部随意调用 —— 容器不再管理该字段生命周期
public void switchToAlipay() {
this.paymentService = applicationContext.getBean("alipayPaymentService");
}
}
这种写法绕过Spring生命周期管理，可能导致AOP失效、事务不生效、内存泄漏等问题。
