SpringBoot这个自动配置坑我跳了三次

• SpringBoot这个自动配置坑我跳了三次*

---

引言

SpringBoot 的自动配置（Auto-Configuration）是其最引以为傲的特性之一，通过@EnableAutoConfiguration和spring.factories机制，开发者可以轻松实现"约定优于配置"的开发体验。然而，正是这种"黑箱魔法"般的便利性，也隐藏了不少陷阱。

在过去的项目中，我曾三次因为自动配置的问题而"踩坑"，甚至导致生产环境的事故。本文将分享这三个典型案例，分析背后的原理，并总结如何避免类似问题。希望通过这些经验，帮助其他开发者更好地驾驭 SpringBoot 的自动配置。

---

主体

坑一：多数据源配置冲突

问题描述

在一个微服务项目中，我们需要同时连接两个不同的数据库：MySQL 和 PostgreSQL。按照 SpringBoot 的默认逻辑，只需在application.yml中配置两个数据源即可：

spring:
  datasource:
    primary:
      url: jdbc:mysql://localhost:3306/db1
      username: root
      password: 123456
      driver-class-name: com.mysql.cj.jdbc.Driver
    secondary:
      url: jdbc:postgresql://localhost:5432/db2
      username: postgres
      password: 123456
      driver-class-name: org.postgresql.Driver

然而，启动时却报错：

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

原因分析

SpringBoot 的自动配置默认会根据spring.datasource的配置尝试创建DataSource Bean。然而，当存在多个数据源时，自动配置无法决定哪个是"主"数据源，从而导致冲突。

解决方案

1. 禁用默认的数据源自动配置：

   @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})

2. 手动配置多数据源，并通过@Primary标注主数据源：

   @Configuration
   public class DataSourceConfig {
       @Bean
       @Primary
       @ConfigurationProperties("spring.datasource.primary")
       public DataSource primaryDataSource() {
           return DataSourceBuilder.create().build();
       }
   
       @Bean
       @ConfigurationProperties("spring.datasource.secondary")
       public DataSource secondaryDataSource() {
           return DataSourceBuilder.create().build();
       }
   }

经验总结

• 多数据源场景下，自动配置可能失效，需要手动干预。
• 理解@Primary的作用，避免 Bean 冲突。

---

坑二：自动配置的条件注解误判

问题描述

在一个 SpringCloud 项目中，我们引入了spring-boot-starter-data-redis，但并未配置 Redis 连接信息。奇怪的是，应用启动时并未报错，而是在调用 Redis 时抛出Connection refused异常。

更诡异的是，另一个同事的本地环境却能正常启动（因为他本地安装了 Redis 服务）。

原因分析

SpringBoot 的自动配置通过条件注解（如@ConditionalOnClass、@ConditionalOnProperty）决定是否生效。对于 Redis，其自动配置类RedisAutoConfiguration的条件是：

@ConditionalOnClass(RedisConnectionFactory.class)
@AutoConfigureAfter(RedisAutoConfiguration.class)

这意味着只要类路径下存在RedisConnectionFactory，自动配置就会尝试创建 Redis 的 Bean，而不会检查 Redis 服务是否可用。

解决方案

1. 显式禁用 Redis 自动配置（如果不需要）：

   spring:
     autoconfigure:
       exclude: org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration

2. 添加 Redis 连接配置或明确标记spring.data.redis.enabled=false。

经验总结

• 条件注解是自动配置的核心，但可能因为环境差异导致行为不一致。
• 生产环境中，务必显式配置关键组件，避免依赖默认行为。

---

坑三：第三方 Starter 的自动配置冲突

问题描述

项目引入了一个第三方 SDK（例如某云服务的 Java SDK），其内部依赖了httpclient。同时，我们的项目也使用了RestTemplate并手动配置了连接池。

然而，在调用第三方 SDK 时，发现超时时间异常（远大于我们配置的值）。经过排查，发现第三方 SDK 的 Starter 自动配置了一个默认的HttpClient，覆盖了我们的自定义配置。

原因分析

许多第三方 Starter 会通过spring.factories注册自己的自动配置类。如果这些配置类未正确限定条件（例如缺少@ConditionalOnMissingBean），就可能覆盖用户的自定义配置。

解决方案

1. 通过@Bean显式覆盖第三方配置：

   @Bean
   public HttpClient customHttpClient() {
       return HttpClientBuilder.create()
           .setConnectionTimeToLive(10, TimeUnit.SECONDS)
           .build();
   }

2. 排除第三方的自动配置：

   @SpringBootApplication(exclude = {ThirdPartyAutoConfiguration.class})

经验总结

• 第三方 Starter 的自动配置可能"悄无声息"地覆盖你的配置。
• 使用@ConditionalOnMissingBean是良好的设计实践，但并非所有库都遵守。

---

总结

SpringBoot 的自动配置是一把双刃剑：它极大地提升了开发效率，但也可能因为"过于智能"而引入隐蔽的问题。通过本文的三个案例，我们可以总结出以下最佳实践：

1. 理解自动配置的底层机制：

   • 熟悉spring.factories和条件注解（如@ConditionalOnClass）的工作原理。
   • 通过--debug模式启动应用，查看自动配置的报告。

2. 显式配置优于隐式约定：

   • 对于关键组件（如数据源、HTTP 客户端），尽量手动配置而非依赖自动配置。
   • 使用exclude排除不必要的自动配置。

3. 警惕第三方 Starter：

   • 阅读第三方库的文档，了解其自动配置逻辑。
   • 在必要时覆盖或排除其自动配置。

希望这些经验能帮助你避免类似的"坑"，更高效地使用 SpringBoot！