springboot自动配置条件优先级由条件注解的与逻辑和配置类加载顺序共同决定：多个条件注解必须全部满足才加载配置类；加载顺序则通过@autoconfigurebefore/after、@order或字典序控制，影响@conditionalonbean等依赖容器状态的条件判断。
SpringBoot自动配置条件优先级决定哪些配置类能被加载、哪些被跳过，直接影响Bean是否注册成功。当多个条件注解共存于一个配置类上时，必须全部满足才进入注册流程；而不同配置类之间的生效顺序，则由加载先后决定，这直接关系到@ConditionalOnBean或@ConditionalOnMissingBean能否正确判断容器状态。
条件注解本身的执行优先级
条件注解没有“高低优先级”之分，它们是与逻辑（AND）关系：一个配置类上同时标注了@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty，三者必须全部返回true，该配置类才会被加载。
任意一个条件失败，整个配置类被跳过，不会进入Bean注册阶段。
例如：@ConditionalOnClass(DataSource.class) && @ConditionalOnMissingBean(DataSource.class) 同时存在，意味着——仅当项目类路径有DataSource类 且 容器中尚未存在DataSource类型的Bean时，该自动配置才生效。
配置类加载顺序的优先级规则
真正影响“谁先谁后”的是配置类的加载顺序，它决定了条件判断的上下文是否就绪。
第一步：Spring Boot启动时，所有候选自动配置类（来自META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports）被读入内存。
第二步：按以下规则排序：
① 显式声明优先：@AutoConfigureBefore(XxxAutoConfiguration.class) 的类排在Xxx之前；@AutoConfigureAfter(YyyAutoConfiguration.class) 的类排在Yyy之后。
② 数值顺序优先：实现Ordered接口或标注@Order(value = -100)的类，数值越小越靠前。
③ 默认顺序：若无显式声明，则按全限定类名字典序排列（如A开头的类早于Z开头的类）。
【关键点】 若A类依赖B类中的Bean（即A含@ConditionalOnBean(B.class)），但排序导致A在B之前加载，则B尚未注册，条件不成立，A被跳过——此时必须用@AutoConfigureAfter(B.class)强制A后于B加载。
用户配置覆盖自动配置的优先级
这不是条件注解层面的优先级，而是配置源层级的覆盖能力。
方法一：通过application.properties/yml设置属性，可覆盖自动配置类中@EnableConfigurationProperties绑定的参数。例如spring.datasource.hikari.maximum-pool-size=20会覆盖HikariDataSourceAutoConfiguration的默认值。
方法二：显式定义@Bean。只要@Bean方法所在配置类被Spring扫描到，且其类型与自动配置试图创建的Bean类型一致，@ConditionalOnMissingBean就会失效——因为条件不满足，自动配置类直接跳过。
注意：自定义@Bean必须确保其配置类比对应自动配置类更早加载，否则自动配置已抢先注册Bean，你的@Bean会被忽略（除非指定primary=true并配合@Qualifier使用）。
条件评估发生的两个阶段
条件判断不是只做一次，而是分两轮执行：
第一轮在parse_configuration阶段：检查@ConditionalOnClass、@ConditionalOnResource、@ConditionalOnProperty等基于环境/类路径/配置文件的条件。此时容器尚未初始化，无法感知已注册的Bean。
第二轮在register_bean阶段：检查@ConditionalOnBean、@ConditionalOnMissingBean、@ConditionalOnSingleCandidate等依赖容器状态的条件。此时ApplicationContext已部分构建，BeanFactory可用。
这意味着：@ConditionalOnClass在启动极早期就筛掉一批配置类；而@ConditionalOnMissingBean必须等到其他配置类完成Bean注册后才能准确判断——所以它的结果高度依赖加载顺序。
