Spring Boot 项目里那些让我想不通的"魔法"

踱鸽&水晶蟹2019-07-152026-04-28

Spring Boot 项目里那些让我想不通的”魔法”

刚开始用 Spring Boot 的时候，我一直有一种奇怪的感觉——代码里明明没有写多少配置，框架就”知道”该怎么运行了。引一个 starter 依赖，对应的功能就自动好了，感觉像魔法一样。

用了很久，我也没深究。直到有一天遇到了一个让我困惑了两个小时的 Bug。

一、问题起点：一个具体的配置不生效的 Bug

那天在做一个模块，需要自定义 RestTemplate 的超时时间。我的做法很常规，写了一个 @Configuration 类，声明了一个 @Bean：

@Configuration
public class HttpConfig {
    @Bean
    public RestTemplate restTemplate() {
        SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
        factory.setConnectTimeout(3000);
        factory.setReadTimeout(5000);
        return new RestTemplate(factory);
    }
}

然后在 Service 里 @Autowired RestTemplate restTemplate，测试了一下，发现超时设置没生效——发出去的请求用的还是默认超时。

我的第一反应是自己写错了，翻了两遍代码，参数没问题。然后开始怀疑：是不是被哪个地方覆盖了？项目里其他地方有没有也声明了 RestTemplate？

于是全局搜了一遍，还真找到了——在一个公共模块里，有另一个 @Configuration 也声明了 RestTemplate，而且没有任何超时设置。两个 Bean 同名，Spring 加载了其中一个，但我不知道加的是哪一个。

这是表面现象，但真正让我困惑的问题在后面：为什么公共模块里的配置类会自动生效？我从来没有手动引用它，也没有显式地开启它。

二、追查过程

带着这个问题，我开始翻 Spring Boot 的源码。

第一步先看 @SpringBootApplication。展开之后发现它是一个组合注解，里面有 @EnableAutoConfiguration。这个注解我知道，”自动配置”嘛，但从来没细想过它是怎么工作的。

进到 @EnableAutoConfiguration 的实现，找到了一个关键类：AutoConfigurationImportSelector。它在 Spring 容器初始化时被调用，核心逻辑是去读一个文件：

META-INF/spring.factories

这个文件在每个 starter 的 jar 包里都有，格式是 key-value，声明了这个 jar 包要自动注册哪些配置类：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  com.example.SomeAutoConfiguration,\
  com.example.AnotherAutoConfiguration

Spring Boot 启动时会扫描所有依赖 jar 包里的这个文件，把里面声明的配置类全部加载进来。这就是为什么我只加了一个 starter 依赖，对应的 Bean 就自动出现了。

找到这里，我的 Bug 也解释清楚了：公共模块的 jar 里有 spring.factories，声明了那个包含 RestTemplate 的配置类，所以它被自动加载进来，和我自己写的冲突了。

然后又看了 @Conditional 系列注解——Spring Boot 的很多自动配置都加了条件判断，比如 @ConditionalOnMissingBean，意思是”如果容器里没有这个 Bean 才生效”。这才是”约定大于配置”的实现方式：框架自带一份默认配置，如果你自己声明了，就用你的；如果没声明，才用默认的。

三、顿悟时刻

理解了 spring.factories 之后，我突然觉得 Spring Boot 的”魔法”一点都不神秘了。

它解决的核心问题是：怎么让一个库被引入时，自动完成初始化，而不需要使用者手动配置？

答案很简单：约定一个固定的文件路径（META-INF/spring.factories），让每个库在这里声明自己的配置类。宿主项目只需要在启动时扫描这些文件，就能自动发现和加载所有依赖的配置。

用自己的话解释：这就像一个”插件市场”，每个 starter 都是一个插件，在自己的包里留了一张”说明卡”（spring.factories），Spring Boot 启动时去收集所有插件的说明卡，按说明把东西装上。

再配合 @Conditional 系列注解，框架可以根据”当前环境里有没有某个类/Bean/配置项”来决定是否激活，实现了既有合理默认值、又允许用户覆盖的效果。

四、延伸思考

这件事给我留下了一个影响比较深的认知：框架的”魔法”，本质上都是约定和扫描。

Spring Boot 用 spring.factories 做自动装配，Dubbo 用 SPI 做扩展点加载，JDBC 驱动用 ServiceLoader 实现多实现切换……它们的核心思路是一样的：

约定一个固定的文件路径或格式
启动时扫描所有 jar 包里的这个路径
根据文件内容执行对应的初始化逻辑

理解了这个模式，当你在一个项目里想实现”引入某个模块就自动激活某个功能”时，你就知道该怎么做了——自己写一个 starter，在里面放一个 spring.factories，按格式声明你的 AutoConfiguration 类。

从这次追查里，我学到的不只是 Spring Boot 怎么工作，而是：一个好的框架设计，应该让”使用者”不需要了解细节也能用好，但让”想深入的人”能顺着脉络一层层找下去。 Spring Boot 的源码结构做到了这一点。