SpringBoot自动配置的坑我帮你踩过了

凌晨三点，线上告警突然炸了------新上的服务在流量高峰时频繁Full GC，而本地测试时明明一切正常。你排查到最后发现，竟是SpringBoot自动配置的一个隐藏陷阱在作祟。今天我们就来聊聊那些年我踩过的自动配置深坑。

1. 多数据源配置：当@Primary遇上自动装配

真实场景

去年做一个金融项目，需要同时连接交易库和日志库。按照"标准做法"用@Configuration声明了两个数据源，并给主库加了@Primary注解。本地测试完美，上线后却偶发"找不到合适的Bean"异常。

根因分析

SpringBoot的DataSourceAutoConfiguration会在classpath存在DataSource时自动配置一个默认数据源。即使你手动声明了多个数据源且标注了@Primary，自动配置的DataSourceInitializerInvoker仍可能先被初始化，导致依赖数据源的Bean提前加载时拿到错误实例。

代码示例

错误写法：

java 复制代码

@Configuration
public class DataSourceConfig {
    @Primary
    @Bean
    public DataSource tradeDataSource() { ... }  // 交易库
    
    @Bean
    public DataSource logDataSource() { ... }    // 日志库
}

正确解法（二选一）：

完全禁用自动配置：

java 复制代码

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)

延迟数据源初始化：

properties 复制代码

spring.datasource.initialization-mode=never

性能代价

在未禁用自动配置的情况下，启动时可能多消耗200-500ms初始化冗余数据源（实测数据：连接池创建+验证耗时）。

2. 条件注解的"短路逻辑"：你以为的条件不成立

真实场景

给内部监控系统引入Redis时，发现@ConditionalOnProperty居然在application.yml明明配置了redis.host的情况下不生效。更诡异的是------同样的配置在测试环境没问题！

根因分析

Spring的条件注解对属性名大小写敏感 ，但YAML文件的属性解析却是大小写不敏感的。当存在redis.host和redis.HOST这类配置时，@ConditionalOnProperty(name = "redis.host")可能与实际加载的配置键不匹配。

避坑姿势

java 复制代码

// 错误：可能匹配不到YAML中的不同大小写变种
@ConditionalOnProperty(name = "redis.host")

// 正确：明确约定命名风格并保持统一
@ConditionalOnProperty(prefix = "redis", name = "host", havingValue = "true")

// 更健壮的写法：配合matchIfMissing
@ConditionalOnProperty(
    prefix = "redis", 
    name = "enabled", 
    havingValue = "true",
    matchIfMissing = true
)

3. 自动配置的顺序陷阱：Bean加载的"先来后到"

真实案例

在自研分布式锁组件时，发现@PostConstruct方法中使用的RedisTemplate有时为null。但明明已经通过@AutoConfigureAfter(RedisAutoConfiguration.class)指定了顺序！

机制解析

自动配置类的加载顺序受以下因素影响：

@AutoConfigureOrder优先级高于@AutoConfigureAfter
配置类内部的@Bean方法调用顺序不可控
使用@DependsOn只能保证Bean实例化顺序，不能保证依赖注入完成

终极解决方案

java 复制代码

@Configuration
public class MyLockAutoConfiguration {

    // 用ObjectProvider延迟注入
    @Bean
    public DistributedLock distributedLock(
            ObjectProvider<RedisTemplate<String, String>> redisTemplateProvider) {
        return new RedisDistributedLock(redisTemplateProvider.getIfAvailable());
    }

    // 显示声明依赖关系（适用于Spring 5.3+）
    @Bean
    @DependsOn("redisTemplate")
    public LockAspect lockAspect() { ... }
}

避坑清单：自动配置的六个高危地带

多模块间配置冲突：当starterA和starterB都自动配置了同名Bean时，取决于classpath加载顺序
条件注解的隐蔽性 ：@ConditionalOnMissingBean可能被同一配置类内的其他@Bean方法干扰
环境差异 ：@Profile和@ConditionalOnCloudPlatform在本地开发与线上环境表现不一致
版本升级陷阱 ：SpringBoot 2.4+对spring.config.activate.on-profile的处理逻辑变化
配置属性绑定时机 ：@ConfigurationProperties Bean可能晚于自动配置类初始化
测试环境特例 ：@MockBean会破坏自动配置的条件判断

自动配置是SpringBoot最精妙的设计，却也最考验工程师对"IoC容器生命周期"的理解深度。下次当你发现某个Bean的行为不符合预期时，不妨先问自己：这个类真的是按我预想的方式加载的吗？

你在项目中还遇到过哪些诡异的自动配置问题？欢迎在评论区分享你的"血泪史"。