按理说，

你是否在项目启动时被一条莫名其妙的异常卡住却找不到根源？其实，SpringBoot 的自动配置本应是开发者的“福音”。但它隐藏的魔法往往会让人踩进陷阱。

自动配置的工作原理

在深入问题之前，先把 SpringBoot 自动配置的主要机制梳理清楚：

1. 条件化加载依赖 @Conditional 系列注解判断是否加载某个配置类。
2. 配置类扫描启动时读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports或旧版 spring.factories将其中列出的类加入容器。
3. 优先级覆盖使用者通过显式定义 @Bean/@Configuration 可以覆盖默认行为。

看似完美，却为「隐式依赖」和「条件竞争」埋下了伏笔。

从踩坑经历来看，DataSource 自动配置的陷阱

问题描述

你有没有在禁用某个 AutoConfiguration 后仍然收到相同错误？老实说，

在微服务项目中我们想自行管理多数据源。于是按照官方文档禁用了默认的数据源自动配置：

spring:
autoconfigure:
exclude:
- org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

只是启动时仍抛出：

Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured.

问题分析

根因出在 spring-boot-actuator 模块。Actuator 的健康检查会加载 DataSourceHealthIndicator{@link}，其条件如下：

@ConditionalOnClass
@ConditionalOnBean
public class DataSourceHealthIndicator { …
}

即使我们排除了 DataSourceAutoConfiguration。只要项目中引入了 spring-boot-starter-jdbc,Actuator 仍会尝试创建健康指示器；而此时没有任何 DataSource Bean 可供匹配，于是触发异常。

方法

1. 关闭数据源健康检查：

   management:
   说到health。db:
   enabled: false
   

2. 显式排除相关 AutoConfiguration：

   @SpringBootApplication(exclude = {
   DataSourceAutoConfiguration.class,DataSourceHealthIndicatorAutoConfiguration.class
   })
   public class MyApplication {…}
   

3. 提供一个占位数据源：If you truly don't need a DB,configure a dummy HikariCP bean to satisfy condition.

更深层次的思考

自动配置的“隐式依赖”——你的盲区在哪里？

SprintBoot 各 starter 之间相互牵连，常见隐式依赖包括：

• spring-boot-starter-web → Tomcat + Jackson
• spring-boot-starter-data-jpa → Hibernate + DataSource
• a starter → actuator health indicators → or beans

If you only look at explicit dependencies in your pom/gradle file。you may miss se hidden links and end up with unexpected auto‑configuration triggers.

条件注解的优先级冲突——谁先谁后决定成败？

The order of configuration classes matters when multiple auto‑configurations compete for same bean:

@Configuration
@ConditionalOnMissingBean
public class MyDataSourceConfig {
@Bean
public DataSource myDataSource { /* custom */ }
}

If YourConfig's loading sequence is later than default DaraSourceAutoConfiguration,default datasource will be created first and your custom bean will be ignored. This explains many “my bean is never used” mysteries.

其他常见自动配置陷阱 — 你可能也遇到过这些痛点！说起来，

1. 多模块项目中的冲突：The parent pom defines certain starters while child modules add ir own. Because classpath scanning follows module order。configurations may be overridden unintentionally.
2. The loading hierarchy is: command‑line> system env> `application.yml`/`application.properties` defaults. A misplaced property in an environment-specific file can silently disable a needed auto‑configuration.
3. Libraries such as MyBatis or Redis register ir own AutoConfigurations. When you also define manual beans of same type,you often have to exclude starter's auto‑configuration explicitly.

​​

​

​​​