SpringBoot自动配置条件注解生效需扫描、判断、注册三环节协同；@EnableAutoConfiguration通过AutoConfigurationImportSelector加载imports文件中的@Configuration类；@ConditionalOnProperty按属性名或前缀匹配配置值；条件失败则BeanDefinition不注册，注入时报错；多条件按序校验，任一失败即排除。
SpringBoot自动配置条件注解生效，依赖于启动时对配置类的扫描、条件判断与BeanDefinition注册三个环节的精确配合，缺一不可。
自动配置类被加载的起点
启动时，@EnableAutoConfiguration 通过 AutoConfigurationImportSelector 加载 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中声明的所有自动配置类。
这些类本身必须标注 @Configuration，否则即使满足条件也不会被当作配置源处理。
若该文件不存在或路径拼写错误（如写成 spring.factories），整个自动配置链将中断，后续所有条件注解都失去作用对象。
@ConditionalOnProperty 生效的关键路径
方法一：基础属性匹配
在配置类上添加 @ConditionalOnProperty(name = "app.feature.enabled", havingValue = "true") → Spring 启动时读取 application.properties 或 application.yml → 提取 app.feature.enabled 的字符串值 → 与 havingValue 严格比对（区分大小写）→ 匹配成功则注册该配置类中全部 @Bean。
注意：如果配置项未定义且未设 matchIfMissing = true，条件直接失败，配置类被跳过。
方法二：前缀 + 属性名组合
使用 @ConditionalOnProperty(prefix = "cache", name = "type", havingValue = "redis") → 实际检查的是 cache.type=redis → 若配置为 cache.type=memcached，则不匹配 → 即使 cache.enable=true 也无效，因为条件只认指定的 name 字段。
将 Spring Boot 2.7 项目升级到 Spring Boot 3.5 的实战流程，覆盖版本基线、依赖坐标替换、Jakarta 迁移、配置兼容、异步上下文传递改造与验证门禁。用于企业多模块 Maven 项目升级与排障。
条件判断失败时的真实行为
第一步：Spring 容器扫描到带 @Conditional 的类或方法
第二步：调用对应 Condition 实现类的 matches() 方法
第三步：返回 false → 该类或方法对应的 BeanDefinition 不会被注册进容器 → 后续任何地方 @Autowired 注入都会报 No qualifying bean 错误
这一步不可逆，也不会抛出异常或日志（除非开启 DEBUG 级别日志），容易误判为“代码没写”而非“条件不满足”。
多个条件同时起作用的顺序
① 所有 @ConditionalOnXxx 注解按声明顺序逐个校验
② 只要其中任意一个返回 false，整个配置类或 Bean 就被排除
③ 例如：@ConditionalOnClass(DataSource.class) 和 @ConditionalOnProperty("spring.datasource.url") 同时存在 → 类路径无 DataSource 时，即使配置了 url 也不生效
④ @ConditionalOnMissingBean 在 BeanDefinition 注册阶段才触发判断，它不依赖配置文件，而是查容器中是否已有同类型 Bean。
