“请说一下SpringBoot自动配置的原理”——这道题几乎出现在每一场Java后端面试中。但吊诡的是，很多候选人背得滚瓜烂熟，面试官却依然摇头。问题出在哪？因为面试官想听的，从来不是一段标准答案，而是你对“为什么这样设计”的理解深度。
先看核心：一个注解背后的连锁反应
自动配置的起点是@SpringBootApplication，它是一个复合注解，其中真正起作用的是@EnableAutoConfiguration。这个注解通过@Import导入了AutoConfigurationImportSelector，后者实现了ImportSelector接口，核心方法是selectImports()。
到这里，很多人的回答就停住了。但面试官想听的是下一步：selectImports()内部调用了getAutoConfigurationEntry()，这个方法做了四件事——读取候选配置类列表、排除用户指定的exclude项、通过条件注解过滤、最后触发自动配置导入事件。这个流程说明了一件事：自动配置不是“全都加载”，而是一场精心设计的筛选。
面试官真正想听的：条件装配的决策逻辑
自动配置类有上百个，但一个Web应用不需要Redis的配置，一个批处理服务也不需要MVC的配置。SpringBoot怎么知道该装配什么？答案藏在@ConditionalOnClass、@ConditionalOnMissingBean这些条件注解里。
以@ConditionalOnClass为例，它本质上是@Conditional(OnClassCondition.class)的派生注解，通过Condition接口的matches()方法返回值来决定是否生效。更巧妙的是，Spring在加载类之前会用ASM字节码技术读取注解元数据，避免了因class不存在而导致的类加载异常。
而@ConditionalOnMissingBean则体现了另一个设计哲学：用户自定义优先。如果开发者手动注册了某个Bean，自动配置就会主动退让。面试官问到这里，其实是在考察你是否理解“自动配置是兜底，而非强制”。
一个容易被忽略的细节：spring.factories的变迁
如果你还在回答“加载META-INF/spring.factories”，那说明你至少落后了两个大版本。SpringBoot 3.0之后，spring.factories已被弃用，自动配置类现在注册在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中。这个变化看似微小，却反映了Spring团队对SPI机制规范化的追求——新的.imports文件格式更简洁，去掉了键值对中冗余的前缀。面试中主动提到这一点，面试官会立刻感受到你在持续跟进技术演进。
如何回答才能脱颖而出
第一层，说清楚“是什么”：注解链路、加载流程、条件过滤。第二层，讲明白“为什么”：条件装配是为了按需加载，@ConditionalOnMissingBean是为了保证用户优先。第三层，加一点“我怎么用”：比如你自己写过一个Starter，在.imports文件中注册了自动配置类，用@ConditionalOnProperty控制开关。能讲到第三层的人，面试官基本会认定你具备工程落地能力。
自动配置的本质，是SpringBoot对“约定优于配置”的一次系统性工程实践。面试官想听的，是你有没有从源码中读出设计者的意图，有没有在生产中验证过这套机制。技术深度不在背诵，而在追问“为什么”的过程里。
