@SpringBootApplication 包含什么？#

核心可以拆为 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan。

• SpringBootConfiguration 表明这是 Boot 配置类，基于 Configuration。
• EnableAutoConfiguration 导入自动配置能力。
• ComponentScan 扫描应用组件，默认以启动类所在包为基础。

业务类放在默认扫描范围之外，需要调整包布局或显式配置扫描；不要以为整个工程所有类都会自动注册。

自动配置怎样工作？#

1
发现自动配置候选类 → 检查类路径、Bean、属性等条件
2
                   → 条件满足时注册所需 Bean

常见条件包括 @ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty。自动配置不是扫描任意依赖包里的全部类，而是加载明确声明的候选配置，再按条件决定是否应用。

例如引入相关依赖、满足数据源属性并且没有自己的 DataSource 时，可以创建数据源配置。如果用户已经提供自己的 Bean，很多自动配置会退让，但要看具体条件，不是所有配置都无条件退让。

Spring Boot 3.x 的自动配置候选通常通过 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 声明；早期版本常通过 spring.factories 中的 EnableAutoConfiguration 条目。这里只区分自动配置注册方式，spring.factories 并非因此在所有其他扩展中消失。

Starter 与自动配置有什么区别？#

Starter 主要组织一组相关依赖，自动配置负责有条件地注册 Bean。引入 Web Starter 会带来 Web 开发所需依赖，随后相应自动配置利用这些依赖和属性组装应用。

开发自定义 Starter 时通常涉及依赖聚合、属性类与自动配置，但第一轮只需说明职责，不必完整实现一个。

配置文件与 Profile#

application.properties 和 application.yml 用于应用配置。配置也可以来自环境变量、命令行参数、外部文件等，最终按属性源优先级合并；同名属性不能仅凭“写在文件里”就判断最终值。

Profile 区分开发、测试、生产等环境，例如 application-dev.yml。@ConfigurationProperties 适合把一组相关配置绑定为类型化对象，并结合校验；@Value 适合简单属性注入或表达式场景。

排查配置不生效时，先确认激活 Profile、配置位置、属性名称和更高优先级覆盖，再检查对应 Bean 是否被创建。

启动与内嵌容器#

SpringApplication.run 大致准备环境、创建并刷新应用上下文、初始化 Bean，并根据应用类型启动 Web 服务等设施。Servlet Web 应用可使用内嵌 Tomcat 等容器，不需要另行手动部署 WAR 才能启动。

ApplicationRunner/CommandLineRunner 适合容器启动后的初始化任务，但其中长时间阻塞会影响启动就绪。Actuator 可提供健康检查和指标等运维入口，暴露范围与认证要按应用需要配置。

自动配置不符合预期怎么查？#

检查依赖是否存在、条件属性是否满足、是否有用户 Bean 使配置退让。可以通过 debug 启动查看条件评估报告，或在正确配置和授权下查看相应诊断端点。明确不需要的自动配置可以使用 exclude 等方式排除，别先手工复制一整套框架配置。

面试回答模板#

Boot 通过 SpringBootApplication 启用配置类、自动配置和组件扫描。Starter 聚合依赖，自动配置读取候选类并根据类路径、Bean 和属性等条件注册对象。应用配置来自多个属性源，Profile 用于环境区分。SpringApplication 创建并刷新容器，Web 应用还能启动内嵌容器；遇到问题通过实际配置和条件报告定位。

自测#

1. 引入 Starter 与自动配置是同一个动作吗？职责不同，前者提供依赖，后者条件化组装。
2. Boot 3.x 自动配置候选还应一律写成 spring.factories 吗？不应，应掌握 imports 方式。
3. 配置文件中的值一定是最终值吗？不是，可能被其他属性源覆盖。