Spring Boot 自动配置是怎么实现的？自定义配置为什么能覆盖默认配置？

知识点详解：默认配置怎样被发现，又怎样知道该退让

从一个数据库连接池的例子开始

假设我们引入数据库相关依赖，希望应用获得一个合适的 DataSource。自动配置可以检查相关类是否存在、当前是否需要这个能力，再结合属性创建默认实现。

如果应用已经提供自己的 DataSource，那么对应的缺失 Bean 条件不成立，默认路径就不再创建它。这叫回退或退让，不等于把一个已经运行的连接池删除后替换。

当然，具体配置使用什么条件，要查看实际自动配置类。不能看到任何自定义 Bean，就认为所有相关默认配置都会一并退出。

候选发现和条件匹配是两步

当前 Spring Boot 使用 jar 中的 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 列出自动配置候选。这和扫描应用包中的普通组件不是同一入口。

找到候选以后，仍然要判断条件。ConditionalOnClass 检查类路径，ConditionalOnMissingBean 检查已有 Bean，属性等条件再决定是否启用某一配置。

所以「依赖放进来了」不意味着「所有功能都打开了」。依赖、属性、Web 应用类型和容器已有对象，都可能改变最终配置。老版本注册机制要结合版本看，不能把旧资料里的文件名当成永久约定。

自定义配置为何能接管默认实现

应用先声明一个被容器识别的实现，默认配置再通过条件判断是否需要补足。这样库可以给开箱即用的默认值，同时保留用户定制的空间。

但缺失 Bean 条件对类型信息和评估时机敏感。Bean 方法返回类型如果过于笼统，就可能影响容器判断；自动配置之间有依赖时，也需要合适的配置顺序。

顺序控制的是定义与条件评估，不代表实际对象一定按同样顺序创建。实例创建还取决于依赖关系。更不能把它理解为靠类名排序争夺一个同名 Bean。

排查从条件报告入手，不靠猜

发现默认 Bean 没出现时，先查看条件评估报告：有没有对应候选，是否被排除，缺失了哪个类，哪个属性不匹配，或者已经存在什么 Bean。

反过来，发现出现了不想要的默认实现，也先找让它成立的条件，再用明确配置或排除处理。随手开启同名 Bean 覆盖，可能掩盖真正的配置冲突。

测试自动配置时，可以用不同依赖和属性组合启动小上下文：用户没有实现时默认出现，有实现时默认退让，依赖缺失时不加载。这比只启动一次完整项目更容易定位。这里讲 Spring Boot 特有机制，不提供伪造的 TS/Python 等价实现。

本题机制参考：Spring Boot Auto-configuration、Creating Your Own Auto-configuration。

面试官继续追问

starter 就是自动配置吗？

不是同一个概念。starter 方便组合依赖，自动配置负责按条件装配。它们常一起使用，但职责不同。

自定义 Bean 一定会覆盖默认 Bean 吗？

不一定。是否退让取决于默认配置的具体条件；同名覆盖还涉及另一个配置机制，不能混称。

自动配置为什么不用普通扫描就行？

库需要一个明确的候选发现入口与条件装配规则，避免被应用包扫描范围偶然影响。当前官方要求自动配置通过 imports 列表加载。

面试速记卡

• 先发现候选，再匹配条件。
• 类路径、属性和已有 Bean 都能影响结果。
• MissingBean 通常让默认实现退让，不是先建再覆盖。
• 组件扫描、自动配置、属性绑定不是一件事。
• 排查查看条件评估报告。