SpringBoot条件注解底层基于@Conditional绑定Condition实现类，在Bean定义注册阶段调用matches()动态决定是否注册组件，依赖ConditionContext提供的上下文资源完成实时校验，全部Condition返回true才注册Bean。
SpringBoot条件注解底层原理是通过@Conditional元注解绑定Condition接口实现类，在Spring容器启动的Bean定义注册阶段，调用matches()方法动态判断是否将被标注的@Bean或@Configuration类纳入IoC容器管理，整个过程依赖上下文环境、类加载器、BeanFactory等资源完成实时条件校验。
@Conditional是所有条件注解的根机制
它本身不包含逻辑，只是一个标记性注解，真正起作用的是其value属性所指定的Condition接口实现类数组。
Spring在解析到@Conditional时，会实例化每个Condition子类，并依次调用其matches(ConditionContext, AnnotatedTypeMetadata)方法。
【ConditionContext中封装了ApplicationContext、Environment、ClassLoader、ResourceLoader等关键上下文对象，缺失任一都可能导致条件误判】
只有全部Condition实现类都返回true，被标注的组件才会被注册；任一返回false，该组件直接跳过加载，不进入BeanDefinitionRegistry。
SpringBoot扩展的条件注解本质是组合封装
比如@ConditionalOnClass(value = DataSource.class)不是独立逻辑，而是被定义为：
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnClassCondition.class)
public @interface ConditionalOnClass { ... }
也就是说，它只是@Conditional(OnClassCondition.class)的语义化别名，真正干活的是OnClassCondition这个SpringBoot内置的Condition实现类。
OnClassCondition继承自SpringBootCondition抽象基类，重写了getMatchOutcome方法——该方法内部调用ClassUtils.isPresent()，利用传入的ClassLoader尝试加载value或name指定的类名。
若类存在且能成功加载，返回ConditionOutcome.match()；否则返回ConditionOutcome.noMatch()。
条件判断发生在Bean定义解析阶段
第一步：Spring容器启动时扫描所有@Configuration类和@Import导入的配置类。
第二步：对每个被@Conditional系列注解标注的@Bean方法或配置类，触发Condition.matches()调用。
第三步：根据matches()返回值决定是否将对应BeanDefinition加入BeanDefinitionRegistry。
注意：这个判断发生在Bean实例化之前，属于“定义阶段”的过滤，不是运行时动态开关。
【一旦BeanDefinition被跳过，后续任何地方都无法通过@Autowired注入该Bean，也不会触发其构造函数或@PostConstruct】
自定义条件注解必须实现Condition接口
方法一：直接实现Condition接口，重写matches方法，从ConditionContext中获取ClassLoader检查类存在性、从Environment读取配置项、从BeanFactory判断Bean是否存在。
方法二：继承SpringBootCondition，复用其日志记录、异常捕获和阶段控制能力，只需专注实现getMatchOutcome抽象方法。
方法三：使用@Conditional组合已有注解（如@ConditionalOnProperty + @ConditionalOnMissingBean），但要注意组合后是“与”关系，全部满足才生效。
自定义注解需用@Conditional(YourCondition.class)标注，并确保YourCondition类在类路径下可被Spring发现和实例化。
