Spring IoC 如何实现条件化装配 Bean？

条件化装配 Bean（Conditional Bean Assembly） 指的是：让 Spring 容器根据特定的条件来决定是否要创建和注册某一个 Bean。

这就像一个智能工厂的生产线，可以根据客户的订单（条件）来决定是安装汽油引擎还是电动机。这个机制是 Spring Boot 自动配置（Auto-configuration）的基石。

核心武器：@Conditional 注解

所有条件化装配都源于 Spring 4.0 引入的 @Conditional 注解。它是一个元注解，意思是它可以被用在其他注解上。

它的工作原理是：
@Conditional 注解需要一个 Condition 接口的实现类。在这个实现类中，你可以编写任意逻辑来判断条件是否满足。如果满足（返回 true），则被注解的 Bean 会被创建；如果不满足（返回 false），则被忽略。

// 这是一个自定义的条件
public class MyCustomCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        // 在这里编写你的判断逻辑
        // 比如，检查某个环境变量是否存在
        return System.getenv("MY_APP_MODE") != null;
    }
}

// 在配置类或Bean方法上使用
@Configuration
@Conditional(MyCustomCondition.class) // <-- 只有当条件满足时，这个配置类及其所有Bean才生效
public class MySpecialConfiguration {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

虽然 @Conditional 很强大，但每次都自己写一个 Condition 类比较繁琐。因此，Spring Boot 在此基础上，提供了一套开箱即用的、更具体的条件注解，覆盖了 99% 的日常场景。

Spring Boot 提供的常用条件注解

这些注解通常用在 @Bean 方法上或 @Configuration 类上。

1. @ConditionalOnProperty (最常用)

条件：当配置文件（application.properties 或 application.yml）中某个属性的值满足指定条件时。

场景：通过一个配置项来控制某个功能的开启或关闭。

// application.properties
// a. 开启短信通知
notification.service.type=sms 
// b. 开启某个高级功能
feature.x.enabled=true

// 只有当 notification.service.type 的值是 "sms" 时，才创建 SmsService 这个 Bean
@Bean
@ConditionalOnProperty(name = "notification.service.type", havingValue = "sms")
public NotificationService smsService() {
    return new SmsService();
}

// 只有当 feature.x.enabled 的值是 "true" 时，才创建 FeatureX Bean
// matchIfMissing = true 表示如果配置文件里根本没写这个属性，也算作条件满足（即默认开启）
@Bean
@ConditionalOnProperty(name = "feature.x.enabled", havingValue = "true", matchIfMissing = true)
public FeatureX featureX() {
    return new FeatureX();
}

2. @ConditionalOnBean 和 @ConditionalOnMissingBean

条件：当 IoC 容器中存在（或不存在）某个类型的 Bean 时。

这是实现“默认实现”和“用户可覆盖”模式的利器。

场景：你提供一个默认的缓存实现（如内存缓存），但允许用户自己定义一个 Redis 缓存 Bean 来覆盖它。

@Configuration
public class CacheAutoConfiguration {

    // **关键**：只有当容器中不存在任何 CacheService 类型的 Bean 时，
    // 才创建下面这个默认的 InMemoryCacheService。
    @Bean
    @ConditionalOnMissingBean(CacheService.class)
    public CacheService inMemoryCache() {
        System.out.println("No custom cache found. Creating default InMemoryCache.");
        return new InMemoryCacheService();
    }
}

// 在用户的配置中：
// 如果用户自己定义了下面这个 Bean...
// @Configuration
// public class MyCacheConfig {
//     @Bean
//     public CacheService redisCache() {
//         return new RedisCacheService(); // 用户自定义的实现
//     }
// }
// ...那么上面的 InMemoryCacheService 就不会被创建。

@ConditionalOnBean 则相反，表示只有当容器中已经存在某个 Bean 时，才创建当前 Bean。这常用于配置依赖于其他组件的 Bean。

3. @ConditionalOnClass 和 @ConditionalOnMissingClass

条件：当应用的 classpath 中存在（或不存在）某个类时。

这是编写 starter 模块的核心。一个功能模块通常依赖于某些第三方库，只有当用户引入了这些库，相关的功能 Bean 才应该被创建。

场景：只有当用户在 pom.xml 中引入了 mysql-connector-java 驱动包时，才自动配置一个 MySQL 相关的 Bean。

@Configuration
// 只有当 classpath 中能找到 "com.mysql.cj.jdbc.Driver" 这个类时，
// 这个配置才会生效。
@ConditionalOnClass(name = "com.mysql.cj.jdbc.Driver")
public class MySqlRelatedConfiguration {
    
    @Bean
    public MySqlHealthIndicator mySqlHealthIndicator() {
        // 创建一个检查 MySQL 健康状态的 Bean
        return new MySqlHealthIndicator();
    }
}

4. @ConditionalOnWebApplication 和 @ConditionalOnNotWebApplication

条件：判断当前应用是否是一个 Web 应用（例如，classpath 中有 Spring MVC 或 WebFlux）。

场景：某些 Bean（如 Filter, Interceptor, WebMvcConfigurer）只在 Web 环境下才有意义。

@Configuration
@ConditionalOnWebApplication // 只有是Web应用时才生效
public class WebSpecificConfig {

    @Bean
    public MyCustomFilter myCustomFilter() {
        return new MyCustomFilter();
    }
}

综合示例：智能通知服务

假设我们要构建一个通知服务，默认使用邮件，但如果用户配置了短信，则优先使用短信。

// 1. application.properties (用户可以不配置，或配置为sms)
// notification.channel=sms

// 2. 核心配置类
@Configuration
public class NotificationAutoConfiguration {

    // 方案A：如果用户配置了短信渠道，创建 SmsService
    @Bean
    @ConditionalOnProperty(name = "notification.channel", havingValue = "sms")
    public NotificationService smsNotification() {
        System.out.println("Condition met: Creating SmsNotificationService.");
        return new SmsNotificationService();
    }

    // 方案B：如果容器里还没有任何 NotificationService 的 Bean，
    // 就创建一个默认的 EmailService 作为“兜底”方案。
    @Bean
    @ConditionalOnMissingBean(NotificationService.class)
    public NotificationService emailNotification() {
        System.out.println("No other NotificationService found. Creating default EmailNotificationService.");
        return new EmailNotificationService();
    }
}

运行结果分析：

• 如果用户配置 notification.channel=sms：SmsNotificationService 会被创建。因为此时容器中已经有了 NotificationService 类型的 Bean，所以 EmailNotificationService 的 @ConditionalOnMissingBean 条件不满足，它不会被创建。最终注入的是 SmsNotificationService。
• 如果用户没有配置 notification.channel：SmsNotificationService 的 @ConditionalOnProperty 条件不满足，它不会被创建。此时容器中没有任何 NotificationService 类型的 Bean，所以 EmailNotificationService 的 @ConditionalOnMissingBean 条件满足，它会被创建。最终注入的是 EmailNotificationService。

总结

通过灵活运用这些条件注解，你就可以编写出非常智能、健壮、可插拔的模块，这也是 Spring Boot “约定优于配置”理念的精髓所在。