@ConditionalOnProperty专为配置驱动开关设计，比自定义@Conditional更安全简洁：内置matchIfMissing、havingValue、多值匹配等健壮支持，避免NPE、类型误判、Bean冲突等问题，且语义清晰、易维护、官方推荐。
直接用 @ConditionalOnProperty 就行，它专为“配置文件控制开关”而生，比手写 @Conditional + Condition 实现更安全、更简洁、更易维护。
为什么不用自定义 @Conditional？
自定义 @Conditional 虽然灵活，但容易出错：比如忘记判空导致 NPE、没处理配置未定义时的行为、无法复用、测试困难。而 @ConditionalOnProperty 内置了对 matchIfMissing、havingValue、类型转换（如 "true"/"false"）、多值匹配（name = {"a", "b"}）的完整支持，Spring Boot 自动化配置底层大量依赖它——说明它足够健壮。
常见错误现象：
-
@Conditional类里调用conditionContext.getEnvironment().getProperty("x")返回null，但没做空判断，直接.equals()→NullPointerException - 配置项写成
feature.enabled: YES，但代码里硬写.contains("true")→ 开关永远不生效 - 多个
@ConditionalBean 同时满足条件 → 启动报NoUniqueBeanDefinitionException
@ConditionalOnProperty 的关键参数怎么配？
核心就三个参数，配错一个就失效：
-
prefix：只写前缀，不带点。例如配置是feature.logging.enabled=true，则prefix = "feature.logging"，不是"feature.logging." -
name：写属性名，不带前缀。上例中是name = "enabled"，不是"feature.logging.enabled" -
havingValue：必须和配置值**字符串完全一致**（区分大小写）。若配置是enabled: on，就得写havingValue = "on"；若想兼容"true"/"ON"，得用@ConditionalOnExpression或改配置规范
示例（正确）：
@Configuration
@ConditionalOnProperty(
prefix = "feature.cache",
name = "strategy",
havingValue = "redis"
)
public class RedisCacheConfig { ... }
对应配置：feature.cache.strategy=redis
多个实现类共存时如何避免冲突？
这是最常踩的坑：两个 @Service 都实现了同一接口，又都用了 @ConditionalOnProperty，但配置值写错或漏配，导致零个或两个 Bean 被注册。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
必须确保：
- 所有同类实现的
@ConditionalOnProperty的name相同（比如都用person.service.impl） - 每个实现的
havingValue值互斥且覆盖全集（如"file"/"db"/"mock"） - 配置文件中该属性有且仅有一个合法值（不能注释掉、不能拼错、不能多写）
- 加
matchIfMissing = false（默认值），防止没配时意外启用某个实现
启动失败提示通常很明确：No qualifying bean of type 'IPersonService' available（没配）或 expected single matching bean but found 2（配重了）。
复杂场景下要不要退回到 @Conditional？
只有两种情况值得考虑：
- 需要组合多个配置项判断，比如
app.env == "prod" && feature.x.enabled == "true"→ 改用@ConditionalOnExpression，它支持 SpEL 表达式，比手写Condition更轻量 - 需要运行时动态刷新开关（如配合 Spring Cloud Config +
@RefreshScope）→@ConditionalOnProperty不支持热生效，此时需放弃条件装配，改用策略模式 +@Value("${x}")注入后 if 判断
其他情况，坚持用 @ConditionalOnProperty。它的语义清晰、边界明确、Spring 官方推荐，而且 IDE 和 Spring Boot Actuator 的 /actuator/configprops 都能直观看到它是否生效。
真正难的从来不是“怎么写”，而是“怎么让开关行为可预期、可追溯、可审计”——@ConditionalOnProperty 把这个责任交给了配置中心和部署流程，而不是藏在 Java 代码里。
