SpringBoot 自动配置类加载顺序与优先级

前面我们已经系统学习了 SpringBoot 自动配置原理、@Conditional 系列条件注解、自定义 Starter，相信很多同学在实际开发中，都会遇到一个非常棘手的痛点：

• • 明明写了自定义 Bean，却没能覆盖 SpringBoot 官方自动配置，到底哪里错了？

• • 两个配置类互相依赖，用 @ConditionalOnBean 判断时，总是出现"条件不满足"，导致 Bean 无法加载？

• • 引入多个第三方 Starter（比如日志、数据源、缓存）后，项目启动报错，提示 Bean 重复定义或依赖缺失？

• • SpringBoot 2.7+ 升级后，自动配置突然失效，和旧版本的加载顺序不一样了？

其实这一切问题的根源，都指向同一个核心知识点------SpringBoot 自动配置类的加载顺序与优先级。

一、为什么加载顺序和优先级如此重要？

在讲具体规则之前，我们先搞懂一个核心问题：为什么加载顺序会影响配置生效？其实本质是「Spring 容器加载 Bean 的机制」和「条件注解的执行时机」在起作用。

1. 加载顺序决定"条件判断"的结果

SpringBoot 加载配置类、创建 Bean 的流程，有一个固定顺序：先排序 → 再逐个解析配置类 → 执行 @Conditional 条件判断 → 满足条件则注册 Bean。

举个最直观的例子：配置类 A 用了 @ConditionalOnBean(B.class)（依赖 B Bean 才能生效），如果 A 比 B 先加载，那么解析 A 时，B 还没被创建，条件判断失败，A 就不会被加载；反之，让 B 先加载，A 后加载，条件满足，A 才能正常生效。

2. 顺序错了必出问题

日常开发中，以下3个场景最容易因为顺序问题踩坑，一定要重点关注：

自定义配置覆盖官方自动配置失败

我们知道，SpringBoot 自动配置用了 @ConditionalOnMissingBean 注解（用户没配我才配），但如果自定义配置比官方自动配置「后加载」，那么官方配置先执行，创建了默认 Bean，自定义配置再执行时，@ConditionalOnMissingBean 条件不满足，就无法覆盖，导致自定义配置失效。

配置类互相依赖，条件判断失效

比如配置类 A 依赖 B，配置类 B 又依赖 A，或者 A 依赖 B，但 A 先加载，都会导致 @ConditionalOnBean 判断失败，最终某个 Bean 无法创建，项目启动报错（NoSuchBeanDefinitionException）。

多个第三方 Starter 配置冲突

比如同时引入了 mybatis-spring-boot-starter 和 spring-boot-starter-jdbc，两者都涉及 DataSource 配置，如果加载顺序混乱，会出现 DataSource Bean 重复定义、连接池配置失效等问题；再比如日志 Starter（logback、log4j2），加载顺序错了会导致日志无法正常输出。

总结

顺序不对 → 条件判断失效 → Bean 不加载/重复加载/加载异常 → 项目启动失败或业务行为异常，这就是为什么我们必须掌握加载顺序和优先级的核心原因。

二、SpringBoot 自动配置加载的"默认规则"

SpringBoot 对配置类的加载，有一套严格的默认优先级体系，从上到下优先级依次降低，我们结合底层加载机制，逐一层拆解，让你不仅知其然，更知其所以然。

核心前提：SpringBoot 配置加载的整体流程

SpringBoot 启动时，加载配置类的整体流程的是：

1. 1. 加载「用户自定义配置」（被 @ComponentScan 扫描的配置类、手动 @Import 的类）；
2. 2. 加载「自动配置类」（来自 spring.factories 或 AutoConfiguration.imports 文件）；
3. 3. 对所有配置类按优先级排序，逐个解析、执行条件判断、注册 Bean。

其中，「排序」是核心步骤，SpringBoot 会通过多种方式，给所有配置类分配"优先级"，优先级高的先加载。

默认优先级体系

1. 优先级最高：用户手动配置

这是优先级最高的配置，也是我们自定义配置能覆盖官方自动配置的根本原因，具体包括：

• • 启动类所在包及子包下，被 @Configuration 标注的配置类（被 @ComponentScan 自动扫描）；

• • 通过 @Import 注解手动导入的配置类（比如 @Import(MyConfig.class)）；

• • 通过 @ImportResource 导入的 XML 配置文件（虽然现在很少用，但优先级同样高）；

• • SpringApplication.setSources() 方法手动设置的配置源。

✅ 注意事项：用户配置之所以优先级最高，是因为 SpringBoot 设计的核心理念是「用户配置优于约定」，优先加载用户配置，能确保用户的自定义需求被优先满足。

✅ 示例：我们写的 RedisConfig、DataSourceConfig 等自定义配置，只要在启动类扫描范围内，就会比官方自动配置先加载，从而覆盖默认配置。

2. 优先级次之：@EnableAutoConfiguration 导入的自动配置

这部分是官方 Starter（如 spring-boot-starter-web、spring-boot-starter-redis）和自定义 Starter 的自动配置类，加载时机在「用户配置之后」，具体来源分为两种（重点区分 SpringBoot 2.7+ 版本差异）：

• • SpringBoot 2.7 之前：来自 classpath 下 META-INF/spring.factories 文件，通过 SpringFactoriesLoader 加载；

• • SpringBoot 2.7 及之后：推荐使用 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件（简称 AutoConfiguration.imports），替代 spring.factories，加载机制更简洁、稳定。

✅ 注意事项：这一梯队的自动配置类，默认是"无序"的，但 SpringBoot 会通过内部规则（比如 @AutoConfigureBefore/After/Order）和预设优先级，给它们排序，避免冲突。

3. 优先级最低：内部默认排序的自动配置

同一批自动配置类（第二梯队）之间，若没有手动设置顺序，SpringBoot 会按「组件类型」预设优先级，从高到低加载，核心顺序如下（高频组件重点记）：

1. 1. 基础框架配置：Spring 上下文（Context）、AOP、事件监听（Event）等核心组件，是所有配置的基础，最先加载；
2. 2. Web 相关配置：Tomcat 服务器（ServerAutoConfiguration）、SpringMVC（WebMvcAutoConfiguration）、WebSocket 等，依赖基础框架；
3. 3. 数据层配置：数据源（DataSourceAutoConfiguration）、事务（TransactionAutoConfiguration）、MyBatis（MybatisAutoConfiguration）、Redis（RedisAutoConfiguration）、MongoDB 等，依赖 Web 或基础框架；
4. 4. 工具类配置：缓存（CacheAutoConfiguration）、邮件（MailAutoConfiguration）等；
5. 5. 监控与测试配置：Actuator（ActuatorAutoConfiguration）、测试相关配置，最后加载，不影响核心业务。

✅ 注意事项：这个默认顺序，是 SpringBoot 经过大量实践优化的，能最大程度避免组件依赖冲突（比如先加载数据源，再加载依赖数据源的 JdbcTemplate）。

三、控制配置加载顺序的核心注解

默认顺序无法满足所有场景（比如自定义配置要依赖官方自动配置，或多个自动配置之间需要调整顺序），这时候就需要用 SpringBoot 提供的核心注解，手动控制顺序。

重点区分：有些注解只对「自动配置类」有效，有些只对「普通配置类」有效，搞错了会导致注解失效，这是很多人踩坑的关键！

第一类：只对「自动配置类」有效的注解

这类注解专门用于调整「第二梯队」的自动配置类顺序，是日常开发中最常用的，必须熟练掌握。

1. @AutoConfigureOrder：按数字指定优先级

✅ 作用

给自动配置类设置优先级，数字越小，优先级越高，用于多个自动配置类之间"排号"，确定加载先后。

✅ 注意事项

该注解的 value 值，对应 Spring 的 Ordered 接口，默认值是 Ordered.LOWEST_PRECEDENCE（最低优先级，值为 Integer.MAX_VALUE）；如果设置为 Ordered.HIGHEST_PRECEDENCE（最高优先级，值为 Integer.MIN_VALUE），则该自动配置类会在所有自动配置类中最先加载。

✅ 代码示例（自定义自动配置类，设置最高优先级）

// 自定义自动配置类，设置最高优先级，比其他自动配置类先加载
@Configuration
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
public class MyHighPriorityAutoConfig {
    // 配置内容...
    @Bean
    public MyBean myBean() {
        return new MyBean();
    }
}

⚠️ 注意事项

1. 1. 该注解只对自动配置类有效（即注册在 spring.factories 或 AutoConfiguration.imports 中的配置类），对普通 @Configuration 类（用户自定义的、被 @ComponentScan 扫描的）无效；
2. 2. 若多个自动配置类设置了相同的 @AutoConfigureOrder 值，SpringBoot 会按类名的字母顺序加载（不推荐设置相同值）。

2. @AutoConfigureBefore：指定在某个自动配置类之前加载

✅ 作用

强制当前自动配置类，在「指定的某个/多个自动配置类」之前加载，比 @AutoConfigureOrder 更灵活（无需记数字，直接指定目标配置类）。

✅ 核心场景

最常用场景：自定义自动配置要覆盖官方自动配置，比如自定义 Redis 配置，要在官方 RedisAutoConfiguration 之前加载，确保 @ConditionalOnMissingBean 生效。

✅ 代码示例（自定义 Redis 自动配置，优先于官方）

// 自定义 Redis 自动配置类，在官方 RedisAutoConfiguration 之前加载
@Configuration
@AutoConfigureBefore(RedisAutoConfiguration.class)
public class MyRedisAutoConfig {
    // 自定义 RedisTemplate，覆盖官方默认配置
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        // 自定义序列化配置...
        return template;
    }
}

⚠️ 注意事项

1. 1. 括号中必须传入「自动配置类的 Class 对象」，且该目标配置类必须是 SpringBoot 能扫描到的（即已注册在自动配置清单中）；
2. 2. 支持传入多个配置类（@AutoConfigureBefore({A.class, B.class})），表示当前配置类在 A、B 之前加载；
3. 3. 不能循环依赖（比如 A 配置 @AutoConfigureBefore(B.class)，B 配置 @AutoConfigureBefore(A.class)），会导致启动死循环。

3. @AutoConfigureAfter：指定在某个自动配置类之后加载

✅ 作用

和 @AutoConfigureBefore 相反，强制当前自动配置类，在「指定的某个/多个自动配置类」之后加载，适用于"依赖其他自动配置"的场景。

✅ 核心场景

典型用途：配置类依赖其他自动配置类创建的 Bean，比如 JdbcTemplate 配置，必须在 DataSourceAutoConfiguration 之后加载（因为需要 DataSource Bean）。

✅ 代码示例（JdbcTemplate 自动配置，依赖数据源）

// 自定义 JdbcTemplate 自动配置，在数据源自动配置之后加载
@Configuration
@AutoConfigureAfter(DataSourceAutoConfiguration.class)
public class MyJdbcAutoConfig {
    // 依赖 DataSource Bean，必须等 DataSourceAutoConfiguration 加载完成
    @Bean
    @ConditionalOnBean(DataSource.class) // 确保 DataSource 已存在
    public JdbcTemplate jdbcTemplate(DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }
}

核心区别

• • @AutoConfigureOrder(10)：给自动配置类「排号」，数字越小越先加载，适合批量排序；

• • @AutoConfigureBefore(A.class)：让当前配置类「站在 A 前面」，适合精准依赖（需要先于某个配置加载）；

• • @AutoConfigureAfter(A.class)：让当前配置类「站在 A 后面」，适合依赖某个配置的 Bean。

第二类：只对「普通配置类」有效的注解

普通配置类，指的是「用户自定义的、被 @ComponentScan 扫描到的 @Configuration 类」（第一梯队），这类配置类不能用上面的三剑客，需要用以下两个注解控制顺序。

1. @Order：控制普通配置类/Bean 的加载顺序

✅ 作用

给普通配置类、Bean 设置优先级，数字越小，优先级越高，和 @AutoConfigureOrder 逻辑一致，但适用范围不同。

✅ 代码示例（两个普通配置类，控制加载顺序）

// 普通配置类1，优先级1，先加载
@Configuration
@Order(1)
public class Config1 {
    @Bean
    public Bean1 bean1() {
        System.out.println("Config1 加载，创建 Bean1");
        return new Bean1();
    }
}

// 普通配置类2，优先级2，后加载
@Configuration
@Order(2)
public class Config2 {
    @Bean
    // 依赖 Config1 中的 Bean1
    public Bean2 bean2(Bean1 bean1) {
        System.out.println("Config2 加载，创建 Bean2");
        return new Bean2();
    }
}

✅ 效果：启动项目后，会先打印"Config1 加载，创建 Bean1"，再打印"Config2 加载，创建 Bean2"，符合 @Order 设定的顺序。

⚠️ 注意事项

1. 1. @Order 对「普通配置类」有效，对「自动配置类」无效（自动配置类用 @AutoConfigureOrder）；
2. 2. @Order 不仅能标注在配置类上，还能标注在 Bean 方法上，控制同一个配置类中不同 Bean 的创建顺序。

2. @DependsOn：强制 Bean 之间的依赖顺序

✅ 作用

比 @Order 更严格，强制指定「某个 Bean 必须在另一个 Bean 之后创建」，不管配置类的加载顺序，只要目标 Bean 没创建，当前 Bean 就不会创建。

✅ 核心场景

适用于"Bean 之间有强依赖"，但配置类加载顺序无法保证的场景，比如 BeanA 依赖 BeanB 的初始化结果，必须让 BeanB 先创建。

✅ 代码示例（强制 Bean 依赖顺序）

@Configuration
public class DependsOnConfig {
    // 先创建 beanB
    @Bean
    public BeanB beanB() {
        System.out.println("创建 BeanB");
        return new BeanB();
    }

    // 强制 beanA 依赖 beanB，必须等 beanB 创建完成后，再创建 beanA
    @Bean
    @DependsOn("beanB") // 这里填 Bean 的名称（默认是方法名）
    public BeanA beanA() {
        System.out.println("创建 BeanA（依赖 BeanB）");
        return new BeanA();
    }
}

⚠️ 注意事项

1. 1. @DependsOn 括号中填的是「Bean 的名称」（默认是 Bean 方法名），不是配置类的名称；
2. 2. 不能循环依赖（比如 beanA 依赖 beanB，beanB 又依赖 beanA），会导致启动报错；
3. 3. @DependsOn 只控制「Bean 的创建顺序」，不控制「配置类的加载顺序」，配置类加载顺序仍由 @Order 或默认规则决定。

第三类：通用注解（所有配置类都有效）

@Import：手动控制配置类加载顺序

@Import 注解可以手动导入配置类，导入的配置类会「优先于当前配置类加载」，而且不受 @Order、@AutoConfigureOrder 等注解的影响，是最灵活的手动控制方式。

// 导入 ConfigA，ConfigA 会优先于当前 Config 加载
@Configuration
@Import(ConfigA.class)
public class Config {
    // 配置内容...
}

✅ 适用场景：需要明确控制多个配置类的加载顺序，且不想用复杂的注解时，直接用 @Import 导入，简单高效。

四、SpringBoot 2.7+ 新机制：@AutoConfiguration 注解

SpringBoot 2.7 版本开始，对自动配置机制进行了优化，推荐使用 @AutoConfiguration 注解替代传统的 @Configuration + @EnableAutoConfiguration，用于声明自动配置类，同时配套使用 AutoConfiguration.imports 文件，替代 spring.factories。

1. 新旧方式对比

对比维度	旧方式（SpringBoot < 2.7）	新方式（SpringBoot ≥ 2.7）
注解	@Configuration + @EnableAutoConfiguration	@AutoConfiguration（替代上面两个注解）
注册文件	META-INF/spring.factories	META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
核心优势	兼容旧版本，使用广泛	语义更清晰、加载机制更稳定、与普通配置类区分更明显
顺序控制	支持 @AutoConfigureBefore/After/Order	同样支持，且优先级规则更统一

2. 新方式实战示例（自定义自动配置类）

步骤1：用 @AutoConfiguration 声明自动配置类

// 新方式：用 @AutoConfiguration 替代 @Configuration + @EnableAutoConfiguration
@AutoConfiguration
@AutoConfigureBefore(RedisAutoConfiguration.class) // 顺序控制依然有效
@ConditionalOnClass(RedisTemplate.class) // 条件注解依然有效
public class MyRedisAutoConfig {
    @Bean
    @ConditionalOnMissingBean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        // 配置内容...
        return new RedisTemplate<>();
    }
}

步骤2：在 AutoConfiguration.imports 中注册

在 src/main/resources/META-INF/spring 目录下，新建文件：org.springframework.boot.autoconfigure.AutoConfiguration.imports，文件中直接写入自动配置类的全类名（无需 key，直接写 value）：

com.example.redis.MyRedisAutoConfig

✅ 注意事项：如果有多个自动配置类，每行写一个全类名，SpringBoot 会按文件中的顺序，结合注解顺序，综合排序加载。

3. 升级注意事项

• • SpringBoot 2.7+ 依然兼容旧方式（spring.factories + @Configuration + @EnableAutoConfiguration），但推荐使用新方式，避免后续版本淘汰；

• • @AutoConfiguration 注解内部已经包含了 @Configuration 和 @EnableAutoConfiguration 的功能，无需重复添加；

• • 新方式的自动配置类，依然支持所有条件注解和顺序控制注解，用法和旧方式一致。

五、如何调试配置类加载顺序

遇到配置顺序问题，光靠理论排查不够，掌握调试技巧，能快速定位哪个配置类先加载、哪个后加载，高效排错。

开启 debug 日志，查看自动配置加载顺序

在 application.yml 中添加 debug: true，启动项目后，控制台会打印「AutoConfigurationReport」，其中包含所有自动配置类的加载顺序、条件判断结果（生效/不生效）。

debug: true # 开启 debug 日志，查看自动配置详情

✅ 关键信息：日志中会显示「Positive matches」（生效的自动配置）和「Negative matches」（未生效的自动配置），以及每个配置类的加载顺序，能快速判断某个配置类是否生效、加载顺序是否正确。

自定义 ApplicationListener，监听配置类加载事件

通过监听 Spring 的 ContextRefreshedEvent 事件，打印所有配置类的加载顺序，精准定位配置类的加载先后。

@Component
public class ConfigLoadListener implements ApplicationListener<ContextRefreshedEvent> {
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        ApplicationContext context = event.getApplicationContext();
        // 获取所有配置类的名称，打印加载顺序
        String[] beanDefinitionNames = context.getBeanDefinitionNames();
        System.out.println("配置类/Bean 加载顺序：");
        for (int i = 0; i < beanDefinitionNames.length; i++) {
            String beanName = beanDefinitionNames[i];
            // 只打印配置类（包含 @Configuration 的类）
            if (context.getBeanDefinition(beanName).getBeanClassName() != null 
                    && context.getBeanDefinition(beanName).getBeanClassName().endsWith("Config")) {
                System.out.println((i+1) + ". " + beanName);
            }
        }
    }
}

使用 IDEA 断点调试，跟踪配置类加载流程

在自动配置类的 @Bean 方法上打断点，启动调试模式，观察断点触发的先后顺序，就能直观看到配置类的加载顺序；同时，还能查看条件注解的判断结果，定位条件不满足的原因。

七、面试高频考点

自动配置加载顺序与优先级，是 SpringBoot 面试的高频考点。

SpringBoot 自动配置类的加载顺序是什么？

答：整体优先级从高到低分为三个梯队：

1. 1. 第一梯队：用户自定义配置（被 @ComponentScan 扫描的 @Configuration 类、@Import 导入的类），优先级最高；
2. 2. 第二梯队：@EnableAutoConfiguration 导入的自动配置类（来自 spring.factories 或 AutoConfiguration.imports）；
3. 3. 第三梯队：内部默认排序的自动配置类（基础框架→Web→数据层→监控测试）。

同一梯队内，可通过注解手动控制顺序（@AutoConfigureBefore/After/Order 等）。

为什么自定义 Bean 能覆盖 SpringBoot 官方自动配置？

答：核心有两个原因：① 优先级：用户自定义配置的优先级高于官方自动配置，会先加载、先注册 Bean；② 条件注解：官方自动配置类用了 @ConditionalOnMissingBean 注解，当用户自定义 Bean 已注册时，官方自动配置的条件不满足，不会再创建默认 Bean，从而实现覆盖。

@AutoConfigureAfter 和 @DependsOn 的区别是什么？（高频追问）

答：两者的核心区别的是「控制范围不同」：

• • @AutoConfigureAfter：只控制「自动配置类的加载顺序」，不控制 Bean 的创建顺序，适用于自动配置类之间的依赖；

• • @DependsOn：只控制「Bean 的创建顺序」，不控制配置类的加载顺序，适用于 Bean 之间的强依赖，不管配置类加载顺序如何，都能保证目标 Bean 先创建。

SpringBoot 2.7+ 对自动配置做了什么优化？

答：主要有两个优化：① 推荐使用 @AutoConfiguration 注解，替代传统的 @Configuration + @EnableAutoConfiguration，语义更清晰；② 推荐使用 AutoConfiguration.imports 文件，替代 spring.factories 文件，用于注册自动配置类，加载机制更稳定，避免旧方式的兼容问题。

如何调试自动配置类的加载顺序？

答：有三种常用方式：① 开启 debug: true，查看控制台的 AutoConfigurationReport，了解自动配置的生效情况和加载顺序；② 自定义 ApplicationListener，监听 ContextRefreshedEvent 事件，打印所有配置类的加载顺序；③ 使用 IDEA 断点调试，跟踪配置类的加载流程和条件判断结果。

八、总结

• •

1. 1. 核心原则：用户配置 > 自动配置，这是自定义配置覆盖官方配置的根本；

• •

• 1. 2. 顺序控制：自动配置用「三剑客」（@AutoConfigureBefore/After/Order），普通配置用 @Order、@DependsOn；

• •

• 1. 3. 版本差异：SpringBoot 2.7+ 推荐 @AutoConfiguration + AutoConfiguration.imports，替代旧方式；

• •

• 1. 4. 排错关键：顺序错 → 条件错 → Bean 失效，学会用 debug 日志和断点调试定位问题；

• •

• 1. 5. 实战口诀：被依赖的先加载，依赖别人的后加载；自定义先加载，自动配置后判断；兜底配置最后加载。

  看到这里，你已经彻底掌握了 SpringBoot 自动配置类的加载顺序与优先级，不管是日常开发中的排错，还是面试中的追问，都能从容应对。

  其实这部分知识的核心，就是"理解顺序的影响，掌握控制顺序的方法"------只要记住优先级规则和核心注解，再结合调试技巧，所有顺序相关的问题，都能迎刃而解。

  收藏这篇，下次遇到配置不生效、Bean 冲突等问题，直接对照梳理，少走弯路～ 关注我，后续持续分享 SpringBoot 底层干货、实战技巧，从入门到进阶，帮你吃透核心知识点，高效搬砖！