SpringBoot自动配置坑了我一晚上，原来问题出在这

• SpringBoot自动配置坑了我一晚上，原来问题出在这*

---

引言

SpringBoot的自动配置（Auto-Configuration）是其核心特性之一，它通过约定大于配置的理念，极大地简化了Spring应用的开发。然而，这种"黑魔法"般的便利性背后，也隐藏着一些容易踩坑的细节。最近，我在一个项目中就因为自动配置的问题折腾了一晚上，最终发现问题的根源竟是一个容易被忽视的配置细节。本文将详细剖析这次踩坑经历，并深入探讨SpringBoot自动配置的工作原理，希望能帮助其他开发者避免类似的"坑"。

---

主体

1. 问题描述

项目背景是一个基于SpringBoot 2.7.x的Web应用，需要整合Redis和自定义的缓存逻辑。按照常规做法，我在pom.xml中引入了spring-boot-starter-data-redis，并在application.yml中配置了Redis的连接信息：

spring:
  redis:
    host: localhost
    port: 6379

然后，我编写了一个自定义的RedisCacheManager，试图覆盖SpringBoot默认的缓存配置：

@Configuration
public class RedisConfig {

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));
        return RedisCacheManager.builder(redisConnectionFactory)
                .cacheDefaults(config)
                .build();
    }
}

启动应用后，我发现自定义的RedisCacheManager并未生效，缓存依然使用了默认的JDK序列化方式。更奇怪的是，断点调试时发现RedisConfig类根本没有被加载！

2. 排查过程

第一步：检查组件扫描

首先怀疑是@Configuration未生效，于是手动在启动类上添加了@ComponentScan，但问题依旧。

第二步：检查依赖冲突

怀疑是依赖冲突导致自动配置未正确加载，通过mvn dependency:tree检查未发现异常。

第三步：开启调试日志

在application.yml中添加以下配置，开启SpringBoot自动配置的调试日志：

logging:
  level:
    org.springframework.boot.autoconfigure: DEBUG

日志显示，RedisAutoConfiguration确实被加载了，但我的RedisConfig未被识别。进一步发现日志中有这样一行：

RedisAutoConfiguration matched:
  - @ConditionalOnClass found required classes 'org.springframework.data.redis.core.RedisOperations', 'org.springframework.data.redis.connection.RedisConnectionFactory'
  - @ConditionalOnMissingBean (types: org.springframework.data.redis.cache.RedisCacheManager; SearchStrategy: all) found no beans

这说明SpringBoot检测到没有自定义的RedisCacheManager，因此加载了默认配置。但明明我的RedisConfig中定义了RedisCacheManager，为什么没有被识别？

第四步：检查加载顺序

突然想到SpringBoot的自动配置是按特定顺序加载的。查阅文档发现，RedisAutoConfiguration会在所有@Configuration类加载完成后才会决定是否启用。于是尝试在RedisConfig上添加@AutoConfigureAfter(RedisAutoConfiguration.class)，但问题依旧。

第五步：深入源码

最终决定深入SpringBoot源码。通过调试发现，RedisAutoConfiguration的RedisCacheConfiguration是通过@Import导入的，而我的RedisConfig由于命名不规范（未遵循*AutoConfiguration的命名约定），被加载的顺序早于RedisAutoConfiguration。这导致SpringBoot认为没有自定义配置，从而覆盖了我的配置。

3. 问题根源

根本原因在于：SpringBoot的自动配置机制对Bean的加载顺序有严格要求。具体来说：

1. SpringBoot会先加载用户定义的@Configuration类。
2. 然后加载自动配置类（通过spring.factories定义）。
3. 如果在用户配置中定义了与自动配置相同的Bean，且没有明确指定加载顺序，自动配置可能会覆盖用户配置。

在我的案例中，由于RedisConfig是一个普通配置类，而RedisAutoConfiguration是一个自动配置类，后者加载时会发现前者已定义的Bean，但由于条件注解的评估时机问题，导致实际未生效。

4. 解决方案

方案一：使用@ConditionalOnMissingBean

修改RedisConfig，明确告诉SpringBoot只有在没有默认RedisCacheManager时才生效：

@Configuration
public class RedisConfig {

    @Bean
    @ConditionalOnMissingBean
    public RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
        // 配置内容不变
    }
}

方案二：调整加载顺序

通过@AutoConfigureAfter确保自定义配置在自动配置之后加载：

@Configuration
@AutoConfigureAfter(RedisAutoConfiguration.class)
public class RedisConfig {
    // 配置内容不变
}

方案三：禁用默认自动配置

在启动类上禁用Redis的自动配置：

@SpringBootApplication(exclude = RedisAutoConfiguration.class)
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

5. 深入理解自动配置机制

通过这次踩坑，有必要深入理解SpringBoot自动配置的工作原理：

1. 条件化加载 ：自动配置类通过@Conditional系列注解（如@ConditionalOnClass、@ConditionalOnMissingBean）实现按需加载。
2. 加载顺序 ：自动配置类的加载顺序由spring.factories中的@AutoConfigureOrder或@AutoConfigureAfter控制。
3. Bean覆盖规则：如果多个配置类定义了相同类型的Bean，后加载的配置会覆盖先加载的配置。
4. 调试技巧 ：通过logging.level.org.springframework.boot.autoconfigure=DEBUG可以查看自动配置的决策过程。

---

总结

SpringBoot的自动配置虽然强大，但也需要开发者对其底层机制有清晰的认识。这次踩坑经历让我深刻理解了以下几点：

1. 自动配置的条件判断逻辑非常严格，需要仔细检查@Conditional注解的条件。
2. 配置类的加载顺序可能影响最终效果，必要时需显式指定顺序。
3. 调试自动配置问题时，开启调试日志是最快定位问题的方式。

希望通过本文的分享，能帮助其他开发者在遇到类似问题时更快找到解决方案。SpringBoot的"约定大于配置"是一把双刃剑，只有深入理解其原理，才能真正驾驭它。