前面我們已經(jīng)系統(tǒng)學習了 SpringBoot 自動配置原理、@Conditional 系列條件注解、自定義 Starter，相信很多同學在實際開發(fā)中，都會遇到一個非常棘手的痛點：

• 明明寫了自定義 Bean，卻沒能覆蓋 SpringBoot 官方自動配置，到底哪里錯了？
• 兩個配置類互相依賴，用 @ConditionalOnBean 判斷時，總是出現(xiàn)“條件不滿足”，導致 Bean 無法加載？
• 引入多個第三方 Starter（比如日志、數(shù)據(jù)源、緩存）后，項目啟動報錯，提示 Bean 重復定義或依賴缺失？
• SpringBoot 2.7+ 升級后，自動配置突然失效，和舊版本的加載順序不一樣了？

其實這一切問題的根源，都指向同一個核心知識點——SpringBoot 自動配置類的加載順序與優(yōu)先級。

一、為什么加載順序和優(yōu)先級如此重要？

在講具體規(guī)則之前，我們先搞懂一個核心問題：為什么加載順序會影響配置生效？其實本質(zhì)是「Spring 容器加載 Bean 的機制」和「條件注解的執(zhí)行時機」在起作用。

1. 加載順序決定“條件判斷”的結果

SpringBoot 加載配置類、創(chuàng)建 Bean 的流程，有一個固定順序：先排序 → 再逐個解析配置類 → 執(zhí)行 @Conditional 條件判斷 → 滿足條件則注冊 Bean。

舉個最直觀的例子：配置類 A 用了 @ConditionalOnBean(B.class)（依賴 B Bean 才能生效），如果 A 比 B 先加載，那么解析 A 時，B 還沒被創(chuàng)建，條件判斷失敗，A 就不會被加載；反之，讓 B 先加載，A 后加載，條件滿足，A 才能正常生效。

2. 順序錯了必出問題

日常開發(fā)中，以下3個場景最容易因為順序問題踩坑，一定要重點關注：

自定義配置覆蓋官方自動配置失敗

我們知道，SpringBoot 自動配置用了 @ConditionalOnMissingBean 注解（用戶沒配我才配），但如果自定義配置比官方自動配置「后加載」，那么官方配置先執(zhí)行，創(chuàng)建了默認 Bean，自定義配置再執(zhí)行時，@ConditionalOnMissingBean 條件不滿足，就無法覆蓋，導致自定義配置失效。

配置類互相依賴，條件判斷失效

比如配置類 A 依賴 B，配置類 B 又依賴 A，或者 A 依賴 B，但 A 先加載，都會導致 @ConditionalOnBean 判斷失敗，最終某個 Bean 無法創(chuàng)建，項目啟動報錯（NoSuchBeanDefinitionException）。

多個第三方 Starter 配置沖突

比如同時引入了 mybatis-spring-boot-starter 和 spring-boot-starter-jdbc，兩者都涉及 DataSource 配置，如果加載順序混亂，會出現(xiàn) DataSource Bean 重復定義、連接池配置失效等問題；再比如日志 Starter（logback、log4j2），加載順序錯了會導致日志無法正常輸出。

總結

順序不對 → 條件判斷失效 → Bean 不加載/重復加載/加載異常 → 項目啟動失敗或業(yè)務行為異常，這就是為什么我們必須掌握加載順序和優(yōu)先級的核心原因。

二、SpringBoot 自動配置加載的“默認規(guī)則”

SpringBoot 對配置類的加載，有一套嚴格的默認優(yōu)先級體系，從上到下優(yōu)先級依次降低，我們結合底層加載機制，逐一層拆解，讓你不僅知其然，更知其所以然。

核心前提：SpringBoot 配置加載的整體流程

SpringBoot 啟動時，加載配置類的整體流程的是：

1. 加載「用戶自定義配置」（被 @ComponentScan 掃描的配置類、手動 @Import 的類）；

2. 加載「自動配置類」（來自 spring.factories 或 AutoConfiguration.imports 文件）；

3. 對所有配置類按優(yōu)先級排序，逐個解析、執(zhí)行條件判斷、注冊 Bean。

其中，「排序」是核心步驟，SpringBoot 會通過多種方式，給所有配置類分配“優(yōu)先級”，優(yōu)先級高的先加載。

默認優(yōu)先級體系

1. 優(yōu)先級最高：用戶手動配置

這是優(yōu)先級最高的配置，也是我們自定義配置能覆蓋官方自動配置的根本原因，具體包括：

• 啟動類所在包及子包下，被 @Configuration 標注的配置類（被 @ComponentScan 自動掃描）；
• 通過 @Import 注解手動導入的配置類（比如 @Import(MyConfig.class)）；
• 通過 @ImportResource 導入的 XML 配置文件（雖然現(xiàn)在很少用，但優(yōu)先級同樣高）；
• SpringApplication.setSources() 方法手動設置的配置源。

? 注意事項：用戶配置之所以優(yōu)先級最高，是因為 SpringBoot 設計的核心理念是「用戶配置優(yōu)于約定」，優(yōu)先加載用戶配置，能確保用戶的自定義需求被優(yōu)先滿足。

? 示例：我們寫的 RedisConfig、DataSourceConfig 等自定義配置，只要在啟動類掃描范圍內(nèi)，就會比官方自動配置先加載，從而覆蓋默認配置。

2. 優(yōu)先級次之：@EnableAutoConfiguration 導入的自動配置

這部分是官方 Starter（如 spring-boot-starter-web、spring-boot-starter-redis）和自定義 Starter 的自動配置類，加載時機在「用戶配置之后」，具體來源分為兩種（重點區(qū)分 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，加載機制更簡潔、穩(wěn)定。

注意事項：這一梯隊的自動配置類，默認是“無序”的，但 SpringBoot 會通過內(nèi)部規(guī)則（比如 @AutoConfigureBefore/After/Order）和預設優(yōu)先級，給它們排序，避免沖突。

3. 優(yōu)先級最低：內(nèi)部默認排序的自動配置

同一批自動配置類（第二梯隊）之間，若沒有手動設置順序，SpringBoot 會按「組件類型」預設優(yōu)先級，從高到低加載，核心順序如下（高頻組件重點記）：

1. 基礎框架配置：Spring 上下文（Context）、AOP、事件監(jiān)聽（Event）等核心組件，是所有配置的基礎，最先加載；

2. Web 相關配置：Tomcat 服務器（ServerAutoConfiguration）、SpringMVC（WebMvcAutoConfiguration）、WebSocket 等，依賴基礎框架；

3. 數(shù)據(jù)層配置：數(shù)據(jù)源（DataSourceAutoConfiguration）、事務（TransactionAutoConfiguration）、MyBatis（MybatisAutoConfiguration）、Redis（RedisAutoConfiguration）、MongoDB 等，依賴 Web 或基礎框架；

4. 工具類配置：緩存（CacheAutoConfiguration）、郵件（MailAutoConfiguration）等；

5. 監(jiān)控與測試配置：Actuator（ActuatorAutoConfiguration）、測試相關配置，最后加載，不影響核心業(yè)務。

? 注意事項：這個默認順序，是 SpringBoot 經(jīng)過大量實踐優(yōu)化的，能最大程度避免組件依賴沖突（比如先加載數(shù)據(jù)源，再加載依賴數(shù)據(jù)源的 JdbcTemplate）。

三、控制配置加載順序的核心注解

默認順序無法滿足所有場景（比如自定義配置要依賴官方自動配置，或多個自動配置之間需要調(diào)整順序），這時候就需要用 SpringBoot 提供的核心注解，手動控制順序。

重點區(qū)分：有些注解只對「自動配置類」有效，有些只對「普通配置類」有效，搞錯了會導致注解失效，這是很多人踩坑的關鍵！

第一類：只對「自動配置類」有效的注解

這類注解專門用于調(diào)整「第二梯隊」的自動配置類順序，是日常開發(fā)中最常用的，必須熟練掌握。

1. @AutoConfigureOrder：按數(shù)字指定優(yōu)先級

? 作用

給自動配置類設置優(yōu)先級，數(shù)字越小，優(yōu)先級越高，用于多個自動配置類之間“排號”，確定加載先后。

? 注意事項

該注解的 value 值，對應 Spring 的 Ordered 接口，默認值是 Ordered.LOWEST_PRECEDENCE（最低優(yōu)先級，值為 Integer.MAX_VALUE）；如果設置為 Ordered.HIGHEST_PRECEDENCE（最高優(yōu)先級，值為 Integer.MIN_VALUE），則該自動配置類會在所有自動配置類中最先加載。

? 代碼示例（自定義自動配置類，設置最高優(yōu)先級）

// 自定義自動配置類，設置最高優(yōu)先級，比其他自動配置類先加載
@Configuration
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
public class MyHighPriorityAutoConfig {
    // 配置內(nèi)容...
    @Bean
    public MyBean myBean() {
        return new MyBean();
    }
}

?? 注意事項

1. 該注解只對自動配置類有效（即注冊在 spring.factories 或 AutoConfiguration.imports 中的配置類），對普通 @Configuration 類（用戶自定義的、被 @ComponentScan 掃描的）無效；

2. 若多個自動配置類設置了相同的 @AutoConfigureOrder 值，SpringBoot 會按類名的字母順序加載（不推薦設置相同值）。

2. @AutoConfigureBefore：指定在某個自動配置類之前加載

? 作用

強制當前自動配置類，在「指定的某個/多個自動配置類」之前加載，比 @AutoConfigureOrder 更靈活（無需記數(shù)字，直接指定目標配置類）。

? 核心場景

最常用場景：自定義自動配置要覆蓋官方自動配置，比如自定義 Redis 配置，要在官方 RedisAutoConfiguration 之前加載，確保 @ConditionalOnMissingBean 生效。

? 代碼示例（自定義 Redis 自動配置，優(yōu)先于官方）

// 自定義 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. 括號中必須傳入「自動配置類的 Class 對象」，且該目標配置類必須是 SpringBoot 能掃描到的（即已注冊在自動配置清單中）；

2. 支持傳入多個配置類（@AutoConfigureBefore({A.class, B.class})），表示當前配置類在 A、B 之前加載；

3. 不能循環(huán)依賴（比如 A 配置 @AutoConfigureBefore(B.class)，B 配置 @AutoConfigureBefore(A.class)），會導致啟動死循環(huán)。

3. @AutoConfigureAfter：指定在某個自動配置類之后加載

? 作用

和 @AutoConfigureBefore 相反，強制當前自動配置類，在「指定的某個/多個自動配置類」之后加載，適用于“依賴其他自動配置”的場景。

? 核心場景

典型用途：配置類依賴其他自動配置類創(chuàng)建的 Bean，比如 JdbcTemplate 配置，必須在 DataSourceAutoConfiguration 之后加載（因為需要 DataSource Bean）。

? 代碼示例（JdbcTemplate 自動配置，依賴數(shù)據(jù)源）

// 自定義 JdbcTemplate 自動配置，在數(shù)據(jù)源自動配置之后加載
@Configuration
@AutoConfigureAfter(DataSourceAutoConfiguration.class)
public class MyJdbcAutoConfig {
    // 依賴 DataSource Bean，必須等 DataSourceAutoConfiguration 加載完成
    @Bean
    @ConditionalOnBean(DataSource.class) // 確保 DataSource 已存在
    public JdbcTemplate jdbcTemplate(DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }
}

核心區(qū)別

• @AutoConfigureOrder(10)：給自動配置類「排號」，數(shù)字越小越先加載，適合批量排序；
• @AutoConfigureBefore(A.class)：讓當前配置類「站在 A 前面」，適合精準依賴（需要先于某個配置加載）；
• @AutoConfigureAfter(A.class)：讓當前配置類「站在 A 后面」，適合依賴某個配置的 Bean。

第二類：只對「普通配置類」有效的注解

普通配置類，指的是「用戶自定義的、被 @ComponentScan 掃描到的 @Configuration 類」（第一梯隊），這類配置類不能用上面的三劍客，需要用以下兩個注解控制順序。

1. @Order：控制普通配置類/Bean 的加載順序

? 作用

給普通配置類、Bean 設置優(yōu)先級，數(shù)字越小，優(yōu)先級越高，和 @AutoConfigureOrder 邏輯一致，但適用范圍不同。

? 代碼示例（兩個普通配置類，控制加載順序）

// 普通配置類1，優(yōu)先級1，先加載
@Configuration
@Order(1)
public class Config1 {
    @Bean
    public Bean1 bean1() {
        System.out.println("Config1 加載，創(chuàng)建 Bean1");
        return new Bean1();
    }
}
// 普通配置類2，優(yōu)先級2，后加載
@Configuration
@Order(2)
public class Config2 {
    @Bean
    // 依賴 Config1 中的 Bean1
    public Bean2 bean2(Bean1 bean1) {
        System.out.println("Config2 加載，創(chuàng)建 Bean2");
        return new Bean2();
    }
}

? 效果：啟動項目后，會先打印“Config1 加載，創(chuàng)建 Bean1”，再打印“Config2 加載，創(chuàng)建 Bean2”，符合 @Order 設定的順序。

?? 注意事項

1. @Order 對「普通配置類」有效，對「自動配置類」無效（自動配置類用 @AutoConfigureOrder）；

2. @Order 不僅能標注在配置類上，還能標注在 Bean 方法上，控制同一個配置類中不同 Bean 的創(chuàng)建順序。

2. @DependsOn：強制 Bean 之間的依賴順序

? 作用

比 @Order 更嚴格，強制指定「某個 Bean 必須在另一個 Bean 之后創(chuàng)建」，不管配置類的加載順序，只要目標 Bean 沒創(chuàng)建，當前 Bean 就不會創(chuàng)建。

? 核心場景

適用于“Bean 之間有強依賴”，但配置類加載順序無法保證的場景，比如 BeanA 依賴 BeanB 的初始化結果，必須讓 BeanB 先創(chuàng)建。

? 代碼示例（強制 Bean 依賴順序）

@Configuration
public class DependsOnConfig {
    // 先創(chuàng)建 beanB
    @Bean
    public BeanB beanB() {
        System.out.println("創(chuàng)建 BeanB");
        return new BeanB();
    }
    // 強制 beanA 依賴 beanB，必須等 beanB 創(chuàng)建完成后，再創(chuàng)建 beanA
    @Bean
    @DependsOn("beanB") // 這里填 Bean 的名稱（默認是方法名）
    public BeanA beanA() {
        System.out.println("創(chuàng)建 BeanA（依賴 BeanB）");
        return new BeanA();
    }
}

?? 注意事項

1. @DependsOn 括號中填的是「Bean 的名稱」（默認是 Bean 方法名），不是配置類的名稱；

2. 不能循環(huán)依賴（比如 beanA 依賴 beanB，beanB 又依賴 beanA），會導致啟動報錯；

3. @DependsOn 只控制「Bean 的創(chuàng)建順序」，不控制「配置類的加載順序」，配置類加載順序仍由 @Order 或默認規(guī)則決定。

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

@Import：手動控制配置類加載順序

@Import 注解可以手動導入配置類，導入的配置類會「優(yōu)先于當前配置類加載」，而且不受 @Order、@AutoConfigureOrder 等注解的影響，是最靈活的手動控制方式。

// 導入 ConfigA，ConfigA 會優(yōu)先于當前 Config 加載
@Configuration
@Import(ConfigA.class)
public class Config {
    // 配置內(nèi)容...
}

? 適用場景：需要明確控制多個配置類的加載順序，且不想用復雜的注解時，直接用 @Import 導入，簡單高效。

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

SpringBoot 2.7 版本開始，對自動配置機制進行了優(yōu)化，推薦使用 @AutoConfiguration 注解替代傳統(tǒng)的 @Configuration + @EnableAutoConfiguration，用于聲明自動配置類，同時配套使用 AutoConfiguration.imports 文件，替代 spring.factories。

1. 新舊方式對比

2. 新方式實戰(zhàn)示例（自定義自動配置類）

步驟1：用 @AutoConfiguration 聲明自動配置類

// 新方式：用 @AutoConfiguration 替代 @Configuration + @EnableAutoConfiguration
@AutoConfiguration
@AutoConfigureBefore(RedisAutoConfiguration.class) // 順序控制依然有效
@ConditionalOnClass(RedisTemplate.class) // 條件注解依然有效
public class MyRedisAutoConfig {
    @Bean
    @ConditionalOnMissingBean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        // 配置內(nèi)容...
        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），但推薦使用新方式，避免后續(xù)版本淘汰；
• @AutoConfiguration 注解內(nèi)部已經(jīng)包含了 @Configuration 和 @EnableAutoConfiguration 的功能，無需重復添加；
• 新方式的自動配置類，依然支持所有條件注解和順序控制注解，用法和舊方式一致。

五、如何調(diào)試配置類加載順序

遇到配置順序問題，光靠理論排查不夠，掌握調(diào)試技巧，能快速定位哪個配置類先加載、哪個后加載，高效排錯。

開啟 debug 日志，查看自動配置加載順序

在 application.yml 中添加 debug: true，啟動項目后，控制臺會打印「AutoConfigurationReport」，其中包含所有自動配置類的加載順序、條件判斷結果（生效/不生效）。

debug: true # 開啟 debug 日志，查看自動配置詳情

? 關鍵信息：日志中會顯示「Positive matches」（生效的自動配置）和「Negative matches」（未生效的自動配置），以及每個配置類的加載順序，能快速判斷某個配置類是否生效、加載順序是否正確。

自定義 ApplicationListener，監(jiān)聽配置類加載事件

通過監(jiān)聽 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 斷點調(diào)試，跟蹤配置類加載流程

在自動配置類的 @Bean 方法上打斷點，啟動調(diào)試模式，觀察斷點觸發(fā)的先后順序，就能直觀看到配置類的加載順序；同時，還能查看條件注解的判斷結果，定位條件不滿足的原因。

六、面試高頻考點

自動配置加載順序與優(yōu)先級，是 SpringBoot 面試的高頻考點。

SpringBoot 自動配置類的加載順序是什么？

答：整體優(yōu)先級從高到低分為三個梯隊：

1. 第一梯隊：用戶自定義配置（被 @ComponentScan 掃描的 @Configuration 類、@Import 導入的類），優(yōu)先級最高；

2. 第二梯隊：@EnableAutoConfiguration 導入的自動配置類（來自 spring.factories 或 AutoConfiguration.imports）；

3. 第三梯隊：內(nèi)部默認排序的自動配置類（基礎框架→Web→數(shù)據(jù)層→監(jiān)控測試）。

同一梯隊內(nèi)，可通過注解手動控制順序（@AutoConfigureBefore/After/Order 等）。

為什么自定義 Bean 能覆蓋 SpringBoot 官方自動配置？

答：核心有兩個原因：① 優(yōu)先級：用戶自定義配置的優(yōu)先級高于官方自動配置，會先加載、先注冊 Bean；② 條件注解：官方自動配置類用了 @ConditionalOnMissingBean 注解，當用戶自定義 Bean 已注冊時，官方自動配置的條件不滿足，不會再創(chuàng)建默認 Bean，從而實現(xiàn)覆蓋。

@AutoConfigureAfter 和 @DependsOn 的區(qū)別是什么？（高頻追問）

答：兩者的核心區(qū)別的是「控制范圍不同」：

• @AutoConfigureAfter：只控制「自動配置類的加載順序」，不控制 Bean 的創(chuàng)建順序，適用于自動配置類之間的依賴；
• @DependsOn：只控制「Bean 的創(chuàng)建順序」，不控制配置類的加載順序，適用于 Bean 之間的強依賴，不管配置類加載順序如何，都能保證目標 Bean 先創(chuàng)建。

SpringBoot 2.7+ 對自動配置做了什么優(yōu)化？

答：主要有兩個優(yōu)化：① 推薦使用 @AutoConfiguration 注解，替代傳統(tǒng)的 @Configuration + @EnableAutoConfiguration，語義更清晰；② 推薦使用 AutoConfiguration.imports 文件，替代 spring.factories 文件，用于注冊自動配置類，加載機制更穩(wěn)定，避免舊方式的兼容問題。

如何調(diào)試自動配置類的加載順序？

答：有三種常用方式：① 開啟 debug: true，查看控制臺的 AutoConfigurationReport，了解自動配置的生效情況和加載順序；② 自定義 ApplicationListener，監(jiān)聽 ContextRefreshedEvent 事件，打印所有配置類的加載順序；③ 使用 IDEA 斷點調(diào)試，跟蹤配置類的加載流程和條件判斷結果。

七、總結

1. 核心原則：用戶配置 > 自動配置，這是自定義配置覆蓋官方配置的根本；

2. 順序控制：自動配置用「三劍客」（@AutoConfigureBefore/After/Order），普通配置用 @Order、@DependsOn；

3. 版本差異：SpringBoot 2.7+ 推薦 @AutoConfiguration + AutoConfiguration.imports，替代舊方式；

4. 排錯關鍵：順序錯 → 條件錯 → Bean 失效，學會用 debug 日志和斷點調(diào)試定位問題；

5. 實戰(zhàn)口訣：被依賴的先加載，依賴別人的后加載；自定義先加載，自動配置后判斷；兜底配置最后加載。

看到這里，你已經(jīng)徹底掌握了 SpringBoot 自動配置類的加載順序與優(yōu)先級，不管是日常開發(fā)中的排錯，還是面試中的追問，都能從容應對。

其實這部分知識的核心，就是“理解順序的影響，掌握控制順序的方法”——只要記住優(yōu)先級規(guī)則和核心注解，再結合調(diào)試技巧，所有順序相關的問題，都能迎刃而解。

收藏這篇，下次遇到配置不生效、Bean 沖突等問題，直接對照梳理，少走彎路～ 關注我，后續(xù)持續(xù)分享 SpringBoot 底層干貨、實戰(zhàn)技巧，從入門到進階，幫你吃透核心知識點，高效搬磚！

以上就是SpringBoot自動配置類加載順序與優(yōu)先級的詳細內(nèi)容，更多關于SpringBoot類加載順序與優(yōu)先級的資料請關注腳本之家其它相關文章！

最新評論