开篇引入

在Spring Boot庞大的技术体系中，条件注解（Conditional Annotations）是自动配置（Auto-Configuration）机制的核心引擎，也是每一位Java开发者迈向进阶之路必须掌握的必学知识点。条件注解允许开发者根据特定的条件动态决定是否加载某个Bean或配置类，从而实现灵活的“按需配置”。-1

但许多学习者在使用Spring Boot时，常常会遇到这样的困扰：明明引入了依赖，Bean却“消失”了；想提供一个默认实现，却被自己的Bean“顶掉”了；面试官问起“为什么pom.xml加个依赖，Bean就自动配好了”，脑子里只有“自动配置”四个字却讲不出原理。本文将系统梳理Spring Boot条件注解的完整知识链路——从为什么需要它，到核心概念讲解，再到代码实战和面试考点，帮助读者建立清晰、可落地的知识体系。

一、痛点切入：传统方式的尴尬与条件装配的诞生

1.1 传统方式：用if-else硬编码解决条件分支

假设我们有一个场景：需要在不同操作系统下初始化不同的Bean——Windows下注册WindowsService，Linux下注册LinuxService。

// 传统做法：在业务代码中写if-else
@Service
public class PlatformService {
    
    @Autowired
    private ApplicationContext context;
    
    public void doSomething() {
        String os = System.getProperty("os.name").toLowerCase();
        if (os.contains("win")) {
            WindowsService service = context.getBean(WindowsService.class);
            service.execute();
        } else if (os.contains("linux")) {
            LinuxService service = context.getBean(LinuxService.class);
            service.execute();
        }
    }
}

1.2 这种写法的问题

• 耦合性高：条件判断逻辑与业务代码耦合在一起，违反了单一职责原则。

• 扩展性差：每新增一个平台（如macOS），就需要修改业务代码。

• 代码冗余：相同类型的条件判断可能散落在多个地方，难以维护。

• 无法复用：这种硬编码的条件逻辑无法被其他模块复用。

1.3 条件装配的设计初衷

Spring团队意识到，与其让开发者手动编写if-else来控制Bean是否创建，不如将这种“条件判断”能力内置到Spring容器的核心流程中。于是，Spring 4.0版本引入了@Conditional注解-23。它的核心思想是：让容器在注册Bean之前，先“咨询”一个条件顾问——条件满足，Bean才注册；条件不满足，直接跳过。-5

二、核心概念讲解：@Conditional注解

2.1 标准定义

@Conditional是Spring Framework 4.0提供的条件装配注解，它的作用是为需要装载的Bean增加一个条件判断，只有满足条件的Bean才会被注册到IoC容器中。-

2.2 拆解关键词

2.3 生活化类比：智能门禁系统

@Conditional就像公司大楼的智能门禁系统。员工刷卡时，门禁系统会向后台数据库“咨询”一个条件顾问：这个人有没有门禁权限？如果有，门自动打开（Bean注册成功）；如果没有，门保持关闭（Bean被忽略）。

2.4 作用与价值

• 按需配置：根据环境、依赖、配置项等因素动态加载Bean

• 解耦：将条件判断逻辑从业务代码中分离到专门的Condition实现类

• 提升启动性能：跳过不满足条件的Bean注册，避免不必要的资源占用-46

三、关联概念讲解：Condition接口与ConditionEvaluator

3.1 Condition接口

Condition接口是@Conditional的“幕后执行者”。它的定义如下：

@FunctionalInterface
public interface Condition {
    boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
}

matches方法接收两个参数：

• ConditionContext：条件上下文，可获取Bean工厂、环境变量、类加载器等信息-

• AnnotatedTypeMetadata：被标注元素的注解元数据

返回true表示条件满足，false表示不满足。-5

3.2 ConditionEvaluator

ConditionEvaluator是Spring内部的“条件评估器”，负责执行Condition接口实现类的判断规则，并将结果返回给Spring上下文，决定Bean是否注册。-15

在Spring上下文初始化时，会创建ConditionEvaluator实例-15。在注册Bean或处理@Bean方法之前，都会调用ConditionEvaluator的shouldSkip()方法，检查是否需要跳过当前Bean的注册。

3.3 三者的逻辑关系

@Conditional（指令） → Condition接口（判断逻辑） → ConditionEvaluator（执行器）

一句话总结：@Conditional是发令枪，Condition是裁判规则，ConditionEvaluator是执行裁判。

四、Spring Boot内置条件注解详解

Spring Boot基于@Conditional封装了一系列开箱即用的条件注解，覆盖了99%的日常开发场景。-5

4.1 六大类条件注解

4.2 对比速查表

五、代码示例：从自定义条件到自动配置实战

5.1 示例一：自定义Condition实现操作系统适配

Step 1：定义Condition实现类

// Windows条件判断
public class WindowsCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        String osName = context.getEnvironment().getProperty("os.name");
        return osName != null && osName.toLowerCase().contains("win");
    }
}

// Linux条件判断
public class LinuxCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        String osName = context.getEnvironment().getProperty("os.name");
        return osName != null && osName.toLowerCase().contains("linux");
    }
}

Step 2：在配置类中使用@Conditional

@Configuration
public class PlatformConfig {
    
    @Bean
    @Conditional(WindowsCondition.class)
    public WindowsService windowsService() {
        return new WindowsService();
    }
    
    @Bean
    @Conditional(LinuxCondition.class)
    public LinuxService linuxService() {
        return new LinuxService();
    }
}

关键点：@Conditional标注在@Bean方法上时，仅对该方法的Bean起控制作用；标注在@Configuration类上时，控制整个类中所有Bean的注册。-6

5.2 示例二：@ConditionalOnMissingBean实现“默认+覆盖”模式

@Configuration
public class DefaultPasswordEncoderConfig {
    
    // 提供默认的密码编码器
    @Bean
    @ConditionalOnMissingBean(PasswordEncoder.class)
    public PasswordEncoder defaultPasswordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

逻辑：如果用户没有自定义PasswordEncoder Bean，则使用默认的BCryptPasswordEncoder；如果用户自定义了，则跳过默认Bean的注册。-5

5.3 示例三：@ConditionalOnProperty实现功能开关

@Configuration
@ConditionalOnProperty(name = "app.cache.enabled", havingValue = "true")
public class CacheConfig {
    
    @Bean
    public RedisCacheManager cacheManager() {
        return new RedisCacheManager();
    }
}

效果：只有当application.yml中配置app.cache.enabled=true时，CacheConfig才会生效，RedisCacheManager才会被注册到容器中。-1

5.4 新旧实现方式对比

六、底层原理支撑

6.1 核心技术栈

条件注解的底层依赖Spring框架的以下核心技术：

6.2 执行时机

条件判断发生在Spring容器初始化的两个关键阶段：

1. BeanDefinition注册阶段：在注册配置类之前，通过ConditionEvaluator校验类上的@Conditional-15

2. @Bean方法处理阶段：在ConfigurationClassPostProcessor中，对每个@Bean方法进行条件校验-15

6.3 常见陷阱

@ConditionalOnMissingBean加载顺序问题：如果自定义Bean和带有@ConditionalOnMissingBean的配置类位于不同的配置阶段，条件检查时可能还没加载到自定义Bean，导致默认Bean仍然被创建。-2

解决方案：使用@AutoConfigureBefore/@AutoConfigureAfter强制指定加载顺序。-2

七、高频面试题与参考答案

面试题1：@Conditional注解的作用是什么？

参考答案：

@Conditional是Spring 4.0引入的条件装配注解，用于根据特定条件决定Bean是否注册到IoC容器。它需要与实现Condition接口的类配合使用，通过matches()方法的返回值（true/false）控制Bean的注册行为。--23

踩分点：Spring版本（4.0） + 条件判断机制（Condition接口 + matches方法） + 应用场景（按需配置）

面试题2：@ConditionalOnMissingBean和@ConditionalOnClass有什么区别？

参考答案：

区别在于检查的对象不同：@ConditionalOnMissingBean检查Spring容器中是否已经存在指定类型的Bean，常用于提供默认实现；而@ConditionalOnClass检查类路径中是否存在指定的Class，常用于检测第三方依赖是否引入。-35

踩分点：准确区分检查对象 + 典型使用场景 + 可举例说明

面试题3：Spring Boot的条件注解底层是如何实现的？

参考答案：

底层依赖三个核心组件：

1. @Conditional：元注解，声明条件判断入口

2. Condition接口：定义matches()方法实现具体判断逻辑

3. ConditionEvaluator：内部执行器，在BeanDefinition注册和@Bean方法处理时调用，通过反射获取Condition实现类并执行matches()方法。-15

执行时机发生在ConfigurationClassPostProcessor处理配置类时。-15

踩分点：三层架构 + ConditionEvaluator角色 + 执行时机

面试题4：Spring Boot如何实现“加个依赖就能自动配置”？

参考答案：

依赖Spring Boot的自动配置机制，核心步骤：

1. 通过spring.factories文件（或新版AutoConfiguration.imports）注册自动配置类

2. Spring Boot启动时读取该文件，获取所有自动配置类

3. 对每个配置类应用条件注解（如@ConditionalOnClass）进行匹配

4. 条件满足的配置类才会被加载，其中的Bean才会注册到容器中-38

踩分点：spring.factories + 条件注解 + 加载流程

八、结尾总结

核心知识点回顾

重点与易错点提醒

⚠️ 易错点1：@ConditionalOnMissingBean的条件检查与Bean加载顺序有关，跨配置阶段时可能失效，需通过@AutoConfigureBefore/After控制顺序。-2

⚠️ 易错点2：@ConditionalOnClass的类名必须使用完全限定名（FQN），拼写错误会导致条件永远不满足。-2

下篇预告

下一篇将深入Spring Boot自动配置的核心源码，从@EnableAutoConfiguration注解入手，带你看清楚spring.factories加载、配置类解析、条件匹配的全过程，彻底搞懂“约定优于配置”的设计哲学背后的实现逻辑。

参考资料：Spring Boot官方文档、runebook.dev、阿里云开发者社区、CSDN博客等