条件判断执行Setter容器注入的核心是按需延迟注入：通过移除@Autowired、提供public Setter、在@PostConstruct中结合配置或Environment判断条件后手动调用Setter实现；优先推荐@Conditional+@Bean静态条件化注册Bean。
条件判断执行 Setter 容器注入，核心在于：不是所有 Bean 都需要在每次初始化时都注入依赖，而是根据运行时条件（如配置开关、环境变量、业务状态等）决定是否调用 Setter 方法完成依赖注入。
明确注入时机与触发条件
Spring 默认的 Setter 注入发生在 Bean 实例化后、初始化前（即 populateBean 阶段），但该过程是无条件的。若需“条件触发”，需绕过默认流程，改由自定义逻辑控制：
- 将依赖字段设为
private且不加@Autowired或@Resource，避免容器自动注入 - 提供 public 的 Setter 方法（如
setServiceXxx(ServiceXxx service)），供后续按需调用 - 在
@PostConstruct、InitializingBean.afterPropertiesSet() 或自定义初始化方法中，先判断条件，再决定是否调用 Setter
在初始化阶段做条件判断
推荐在 Bean 初始化完成后统一处理，既保证依赖对象已创建，又保留控制权：
- 使用
@PostConstruct方法，读取@Value("${feature.enabled:true}")或Environment获取配置 - 结合
ApplicationContext手动获取目标 Bean（如context.getBean(ServiceXxx.class)），再传入 Setter - 注意：若目标 Bean 是 prototype 作用域，需确保每次获取的是新实例；若为 singleton，直接注入即可
避免循环依赖与注入顺序问题
条件注入容易引发隐式依赖链断裂或顺序错乱：
- 不要在构造器或
@PostConstruct中调用尚未初始化的其他 Bean 的 Setter（尤其当它们也依赖当前 Bean 时） - 若条件依赖另一个 Bean 的状态（如 “只有当 DB 连接成功才注入 DAO”），建议将该判断逻辑上移至 FactoryBean 或 Configuration 类中
- 可借助
ObjectProvider<Xxx>延迟解析依赖，配合if (provider.getIfAvailable() != null)安全判断
替代方案：用 @Conditional + @Bean 组合更清晰
若条件相对静态（如 profile、class presence、property 值），优先使用 Spring Boot 的条件化配置：
- 定义多个
@Bean方法，分别标注@ConditionalOnProperty(name="xxx.enabled", havingValue="true") - 让容器根据条件决定是否注册该 Bean，再通过常规 Setter 或构造器注入到目标类
- 这种方式更符合 Spring 设计哲学，测试友好，且无需手动管理注入时机
