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 {@Overridepublic boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {// 在这里编写你的判断逻辑// 比如,检查某个环境变量是否存在return System.getenv("MY_APP_MODE") != null;}
}// 在配置类或Bean方法上使用
@Configuration
@Conditional(MyCustomCondition.class) // <-- 只有当条件满足时,这个配置类及其所有Bean才生效
public class MySpecialConfiguration {@Beanpublic 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 {@Beanpublic MySqlHealthIndicator mySqlHealthIndicator() {// 创建一个检查 MySQL 健康状态的 Beanreturn new MySqlHealthIndicator();}
}
4. @ConditionalOnWebApplication
和 @ConditionalOnNotWebApplication
条件:判断当前应用是否是一个 Web 应用(例如,classpath 中有 Spring MVC 或 WebFlux)。
场景:某些 Bean(如 Filter
, Interceptor
, WebMvcConfigurer
)只在 Web 环境下才有意义。
@Configuration
@ConditionalOnWebApplication // 只有是Web应用时才生效
public class WebSpecificConfig {@Beanpublic 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
。
总结
注解 | 条件 | 主要用途 |
---|---|---|
@ConditionalOnProperty | 配置文件中属性的值 | 功能开关,按配置切换实现 |
@ConditionalOnMissingBean | IoC 容器中缺少某个 Bean | 提供可被用户覆盖的默认实现(兜底 Bean) |
@ConditionalOnBean | IoC 容器中存在某个 Bean | 当某个依赖准备好后,才装配当前 Bean |
@ConditionalOnClass | Classpath 中存在某个类 | 检测是否引入了某个依赖库,是开发 starter 的核心 |
@ConditionalOnWebApplication | 当前是 Web 应用环境 | 装配只在 Web 环境下有意义的 Bean |
@Conditional | 自定义 Condition 类 | 实现高度定制化的、复杂的判断逻辑 |
通过灵活运用这些条件注解,你就可以编写出非常智能、健壮、可插拔的模块,这也是 Spring Boot “约定优于配置”理念的精髓所在。