Spring Boot 面试题

本页只放 Spring Boot 面试标准回答、项目话术、常见追问和知识点跳转。自动配置、启动流程、Starter、配置绑定、内嵌 Tomcat 等底层原理统一放到对应知识点页学习。

使用方式

flowchart TD
    A["面试页：先背会怎么答"] --> B["知识点页：再理解为什么"]
    B --> C["回到项目：说清怎么落地"]

高频问题

面试题	标准回答	原理知识点
怎么判断 Spring Boot 是否真正学懂	不能只会背 @SpringBootApplication 和写 Controller。真正学懂要能讲清启动流程、配置加载、自动配置、Starter、条件注解、内嵌 Tomcat、Web 请求链路、扩展点、Actuator、生产排查和商业 Starter 落地，并能用 Demo 证明。	Spring Boot 从零到精通验收清单
Spring Boot 怎么从零学到生产级	不能只会写 Controller。要按启动类、SpringApplication.run、Starter、自动配置、配置体系、内嵌 Tomcat、请求链路、统一异常参数校验、扩展点、Actuator、部署和线上排查这条主线学习。	Spring Boot 从零到生产级掌握
Spring Boot 和 Spring 有什么区别	Spring 提供 IOC、AOP、事务、MVC 等基础能力；Spring Boot 是基于 Spring 的工程化增强，核心是自动配置、Starter、内嵌服务器和约定优于配置，让项目更快启动和落地。	Spring Boot 从零到生产级掌握、Spring Boot总览、Spring IOC
为什么Boot 3最低要求Java 17	Boot 3基于Spring Framework 6，而Spring 6把Java 17作为运行基线；这是class版本和框架依赖的硬约束，不是建议项。Java 8或11 JVM无法加载Boot 3依赖的Java 17字节码。	Java 17+与Boot 3：Java基线
Boot 2.7和Boot 3核心区别	Boot 3基于Spring 6和Java 17，迁移到Jakarta命名空间，并演进了自动配置注册、可观测性、AOT及生态依赖。升级必须同时核对Servlet容器、Validation、Persistence、Security、Cloud、Starter和Agent。	Java 17+与Boot 3：核心变化
javax改成jakarta为什么不只是换import	JVM按完全限定类名识别类型，javax.servlet.Filter和jakarta.servlet.Filter是不同类型；第三方Jar字节码仍会引用旧类型，因此必须升级或重新编译整个依赖链。	Jakarta迁移原理
Boot 2迁Boot 3怎样降低风险	先补契约测试并站到Boot 2.7基线，再让2.7运行于Java 17，把JDK变化与框架变化拆开；随后升级Boot、Cloud和Jakarta兼容组件，做集成、性能、故障与灰度验证，并保留可执行回滚。	Boot 3迁移流程
@SpringBootApplication 是什么	它是组合注解，通常可以理解为 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan 的组合，分别负责配置类、自动配置和组件扫描。	启动原理、Spring IOC
自动配置原理是什么	Spring Boot 通过 @EnableAutoConfiguration 导入 AutoConfigurationImportSelector，启动时读取候选自动配置类。Boot 2.6及更早常见spring.factories；Boot 2.7已支持并推荐AutoConfiguration.imports；Boot 3使用imports机制。候选类再经条件判断注册BeanDefinition，最终由Spring IOC创建Bean。	自动配置原理、版本边界
自动配置为什么不是魔法	因为它不是运行时乱猜，而是候选配置类 + 条件注解 + BeanDefinition + IOC 生命周期。依赖在 classpath 中、配置项满足、容器缺少用户 Bean 时，默认配置才生效。	自动配置原理、Spring核心扩展点
自动配置完整流程怎么讲	从 SpringApplication.run 开始，先准备 Environment，再创建 ApplicationContext，解析 @SpringBootApplication，通过 @EnableAutoConfiguration 导入 AutoConfigurationImportSelector，读取候选自动配置类，处理排除、去重、排序，再由条件注解决定是否注册 BeanDefinition，最后在 refresh() 阶段创建 Bean。	自动配置与扩展点全过程
条件注解什么时候判断	条件注解可能在配置类解析和 BeanDefinition 注册阶段判断。类级条件决定整个自动配置类是否参与解析，方法级条件决定某个 @Bean 是否注册。条件主要依赖 classpath、Environment、已有 BeanDefinition、Web 应用类型和资源。	自动配置原理：条件注解到底什么时候判断
@ConditionalOnClass 为什么能优雅跳过缺依赖	Boot 会尽量基于注解元数据和 classpath 判断类是否存在，而不是直接初始化缺失类。公共 starter 常用 @ConditionalOnClass 或 name 写法，避免业务项目没引入某依赖时启动直接报 ClassNotFoundException。	自动配置原理：ConditionalOnClass
@ConditionalOnMissingBean 有什么坑	它判断的是当前容器中已经存在的 BeanDefinition 或 Bean，不是预知未来所有 Bean。自定义 starter 要让用户配置优先，默认 Bean 加 @ConditionalOnMissingBean，不要过早 getBean()，必要时用自动配置排序保证判断依据稳定。	自动配置原理：MissingBean时机坑
Spring Boot 自动配置怎么落到项目	可以把公共能力拆成 SDK、autoconfigure、starter。SDK 放纯客户端，autoconfigure 放配置属性、自动配置类、条件注解、HealthIndicator、指标和 FailureAnalyzer，starter 只聚合依赖。业务项目引入 starter 后，Boot 读取自动配置清单，条件匹配就创建默认 Bean，用户也可以通过自定义 Bean 覆盖默认实现。	Spring Boot商业场景训练营
Boot 2 和 Boot 3 自动配置声明区别	Boot 2.6及更早常见spring.factories；Boot 2.7已经支持并推荐AutoConfiguration.imports且兼容旧方式；Boot 3移除了通过旧EnableAutoConfiguration key注册候选类的方式。不能扩大为“Boot 3完全不使用spring.factories”。	自动配置版本边界
为什么自定义 Bean 后默认配置会失效	很多自动配置使用 @ConditionalOnMissingBean，表示容器里没有用户自定义 Bean 时才创建默认 Bean。用户自己声明 Bean 后，Boot 默认实现会让位。	Starter机制、Spring IOC
Starter 是什么	Starter 是场景化依赖入口，通常聚合 SDK 和 autoconfigure；autoconfigure 提供属性类、条件和默认 Bean。业务应用引入依赖后，Boot 从版本对应声明文件发现候选配置，条件满足才注册 BeanDefinition，最后由 Spring 容器创建 Bean。	Starter机制：五个概念、Starter全过程原理
Starter 和自动配置什么关系	Starter 主要负责依赖入口，自动配置负责真正装配 Bean。starter 把 SDK 和 autoconfigure 带进 classpath，Spring Boot 再通过 spring.factories 或 AutoConfiguration.imports 发现自动配置类，经过条件注解判断后把默认 Bean 注册到容器。	Starter全过程原理：开箱即用全过程、自动配置原理
为什么要拆 starter 和 autoconfigure	starter 最好只做依赖聚合，autoconfigure 放自动配置类、属性类、条件类和默认 Bean。这样职责清楚，自动配置逻辑可以单独测试，SDK 也可以独立复用，避免 starter 模块变成大杂烩。	Starter全过程原理：模块边界
自定义 Starter 要注意什么	Starter 要拆清 starter 和 autoconfigure 边界，用 @ConfigurationProperties 管配置，用 @ConditionalOnClass 判断依赖是否存在，用 @ConditionalOnProperty 提供开关，用 @ConditionalOnMissingBean 尊重用户自定义，不能把具体业务规则强塞进公共 Starter。	Starter全过程原理、自动配置原理
Starter 没生效怎么排查	先用 dependency tree 确认运行时依赖，再检查 autoconfigure Jar 中是否存在版本对应的声明文件；然后在 conditions 报告搜索目标配置类，判断未成为候选、被 exclude 还是条件不匹配；Positive match 后继续检查配置绑定、构造异常和用户 Bean 是否触发默认让位。	Starter机制：证据化排查、Starter全过程原理
conditions 报告怎么看	先在报告里搜索目标自动配置类；没有出现就查 starter 依赖和声明文件；出现但在 Negative matches 就看缺依赖、配置项、Web 类型或资源；Positive matches 但 Bean 没出来就看 @ConditionalOnMissingBean 是否让位、配置绑定是否失败、Bean 创建是否异常。	自动配置原理：conditions报告怎么看
Spring Boot 启动流程	Spring Boot 启动从 SpringApplication.run 开始，先创建 SpringApplication，推断应用类型，加载初始化器和监听器，然后准备 Environment、读取配置和 Profile，再根据应用类型创建 ApplicationContext。之后解析启动类、组件扫描和自动配置，把 BeanDefinition 注册到容器，执行 refresh() 创建非懒加载单例 Bean。Servlet Web 应用会在刷新过程中创建并启动内嵌 Tomcat，最后发布启动完成事件并执行 Runner。	启动流程全过程原理、启动原理
Spring Boot 一次 HTTP 请求怎么走	请求先进入内嵌 Tomcat，再经过 Filter 链，到 DispatcherServlet，由 HandlerMapping 找到 Controller，执行参数解析和校验，进入 Controller、Service、Mapper 或 Repository，访问数据库、Redis、MQ 等下游，最后通过消息转换器序列化成 JSON 返回。	Spring Boot 从零到生产级掌握
Spring Boot 常见扩展点有哪些	启动早期可以用 EnvironmentPostProcessor，容器刷新前用 ApplicationContextInitializer，Bean 阶段用 Spring 后置处理器，启动完成后用 ApplicationRunner，Web 链路用 Filter、Interceptor、ArgumentResolver，监控用 HealthIndicator 和 Micrometer，失败诊断用 FailureAnalyzer。	Spring Boot扩展点
扩展点怎么选	先判断要干预哪个生命周期阶段：配置读取前用 EnvironmentPostProcessor，动态注册 BeanDefinition 用 BeanDefinitionRegistryPostProcessor，修改 Bean 定义用 BeanFactoryPostProcessor，Bean 初始化增强用 BeanPostProcessor，启动完成预热用 Runner，请求链路用 Filter/Interceptor/ArgumentResolver，监控诊断用 HealthIndicator/MeterBinder/FailureAnalyzer。	自动配置与扩展点全过程、Spring Boot扩展点
BeanDefinitionRegistryPostProcessor 和 BeanFactoryPostProcessor 区别	BeanDefinitionRegistryPostProcessor 更早，主要用于新增、删除、批量注册 BeanDefinition，例如 Mapper、Feign Client、客户端代理；BeanFactoryPostProcessor 主要修改已经注册好的 BeanDefinition。两者都不应该提前获取业务 Bean。	Spring Boot扩展点、Spring核心扩展点
ImportBeanDefinitionRegistrar 做什么	它通常配合 @Import 或自定义 @EnableXxx 注解，根据注解元数据或扫描结果编程式注册 BeanDefinition。它适合框架集成，不适合普通业务代码炫技使用。	Spring Boot扩展点
扩展点选错为什么会出问题	因为 Spring Boot 启动是分阶段的。越早的扩展点能改配置和 BeanDefinition，但不能访问业务 Bean；越晚的扩展点能拿到完整 Bean，但自动配置条件、配置绑定和 Bean 创建可能已经结束。比如配置解密放到 Runner 就太晚，BeanFactoryPostProcessor 里 getBean 可能导致 Bean 过早创建，绕开 AOP 和事务代理。	扩展点选错为什么会出问题
SmartLifecycle 适合什么场景	SmartLifecycle 适合管理长期运行组件的启动和停止顺序，例如消息消费者、采集调度器、长连接客户端。它可以通过 phase 控制先后顺序，并在应用关闭时优雅停止。不要在构造方法或 @PostConstruct 里随便启动后台线程，否则依赖可能未就绪，关闭也不可控。	SmartLifecycle
ResponseBodyAdvice 做什么	ResponseBodyAdvice 在 Controller 返回对象之后、消息转换器写响应之前执行，适合做统一响应包装、补充 traceId 等协议层增强。它不适合写业务判断，并且要排除文件下载、字符串响应、已包装结果等特殊场景，避免误包装。	ResponseBodyAdvice
FailureAnalyzer 和 ExitCodeGenerator 区别	FailureAnalyzer 面向人，把启动异常翻译成清晰原因和修复建议；ExitCodeGenerator 面向脚本、容器和 CI/CD，用退出码表达失败类型。自定义 Starter 可以二者配合，既让开发者看懂缺什么配置，也让平台识别启动失败原因。	FailureAnalyzer、ExitCodeGenerator
Readiness 和 Liveness 有什么区别	Liveness 表示进程是否还活着，常用于判断是否需要重启；Readiness 表示应用是否准备好接流量，常用于 K8s Service 是否转发流量。应用启动但字典、连接池、消息订阅、外部依赖还没准备好时，Liveness 可以是可用，Readiness 应该暂时不可用。	AvailabilityState
自动配置排序是不是 Bean 创建顺序	不是。@AutoConfigureBefore、@AutoConfigureAfter 主要影响自动配置类解析和 BeanDefinition 注册顺序，最终 Bean 创建还受依赖关系、懒加载、@DependsOn、条件注解和 BeanPostProcessor 影响。	自动配置原理
自动配置没生效怎么排查	先打开 debug=true 或 /actuator/conditions，确认自动配置类是否在候选列表，再看是否被 exclude、条件是否匹配、classpath 是否缺依赖、配置项是否写错、是否已有用户 Bean、Bean 创建或配置绑定是否异常。	自动配置与扩展点全过程
refresh() 为什么重要	refresh() 是 Spring 容器真正启动的核心阶段，会准备 BeanFactory、执行 BeanFactoryPostProcessor、注册 BeanPostProcessor、初始化事件广播器、创建非懒加载单例 Bean。AOP、事务、生命周期回调、自动配置 Bean 的创建都离不开这个阶段。	启动流程全过程原理：refresh、Spring Bean生命周期
内嵌 Tomcat 什么时候启动	Servlet Web 应用会创建 ServletWebServerApplicationContext，它在 refresh() 的 onRefresh() 阶段调用 createWebServer()，通过 ServletWebServerFactory 创建 Tomcat，注册 Servlet、Filter、Listener，最后绑定端口并开始接收请求。	启动流程全过程原理：内嵌Tomcat、启动原理
Spring Boot 配置体系是什么	Spring Boot 配置体系是把端口、数据库、Redis、第三方接口、线程池、日志级别等环境差异从代码中抽离出来。启动时 Boot 会加载多个配置源到 Environment，再通过 Binder 绑定到 @ConfigurationProperties 对象，供自动配置和业务 Bean 使用。	配置体系全过程原理、配置体系
配置文件优先级怎么理解	Spring Boot 会从配置文件、Profile、环境变量、JVM 参数、命令行参数、配置中心等多个来源加载属性。一般越外部、越临时、越明确指定的配置优先级越高。线上排查时不能只看文件值，要看最终 Environment 中生效的值以及来源。	配置体系全过程原理：优先级
@Value 和 @ConfigurationProperties 怎么选	少量简单值可用 @Value；一组有前缀、有嵌套、有类型转换、有校验需求的配置，应该用 @ConfigurationProperties。商业项目里的客户端、线程池、上传、限流、外部接口配置更推荐配置属性类。	配置体系全过程原理
Profile 有什么用	Profile 用来区分不同环境配置。公共配置放 application.yml，环境差异放 application-dev.yml、application-prod.yml 等，通过 spring.profiles.active 激活。这样同一份代码可以在开发、测试、生产使用不同参数。	配置体系全过程原理：Profile
配置为什么能绑定到对象	Spring Boot 会把配置源合并到 Environment，然后 Binder 根据 @ConfigurationProperties 的 prefix 找到相关属性，进行宽松名称匹配、类型转换、对象填充和校验，最终把配置类注册为 Bean。	配置体系全过程原理：Binder
配置不生效怎么排查	先看 active profile，再看配置源是否加载，检查环境变量、命令行参数、配置中心是否覆盖本地文件；然后看属性名是否写对、类型是否能转换、配置类是否注册；最后用 /actuator/env、/actuator/configprops、/actuator/conditions 定位最终值、绑定结果和自动配置条件。	配置体系全过程原理：排查
Filter 和 Interceptor 区别	Filter 属于 Servlet 规范，在 DispatcherServlet 前执行，不知道具体 Controller；Interceptor 属于 Spring MVC，在 HandlerMapping 后、Controller 前后执行，能拿到 handler 信息。traceId、底层过滤适合 Filter，权限、审计、接口日志常用 Interceptor。	Spring Boot扩展点
Runner 适合做什么	ApplicationRunner、CommandLineRunner 在容器启动完成后执行，适合做轻量缓存预热、启动检查、注册状态等。不能放不可控长任务，否则会拖慢启动甚至导致启动失败。	启动流程全过程原理：Runner、Spring Boot扩展点
Actuator 怎么扩展	可以通过 HealthIndicator 增加自定义健康检查，通过 Micrometer 注册业务指标，通过 Endpoint 暴露运维信息。生产环境要控制端点暴露和权限。	Spring Boot扩展点、Actuator监控
Spring Boot 项目怎么分层	Web 层负责 HTTP 协议、格式校验和响应转换；Application Service 负责用例编排、事务和幂等入口；Domain 表达业务不变量；Repository/Mapper 负责持久化；Client/Gateway 隔离外部协议。分层的目的不是增加目录，而是隔离 HTTP、业务、数据库和第三方变化。	Web工程：分层边界
DTO、Entity、Domain、VO 为什么不能全部共用	请求 DTO 是外部输入合约，Entity 对应持久化结构，Domain 表达业务规则，Response/VO 是外部输出合约。全部共用会产生越权赋值、敏感字段泄露、懒加载序列化问题，并让 API 与库表强耦合。	Web工程：模型边界
参数校验通过是否代表业务合法	不代表。@Valid 主要验证非空、长度、格式、金额范围等结构约束；商品是否存在、订单状态能否变化属于业务校验；requestId 唯一、库存不能为负等并发不变量还要靠数据库唯一约束或原子机制兜底。	Web工程：请求校验
为什么事务通常放在 Service 层	Service 通常表达一个完整用例，能覆盖多个数据操作，又不会把 JSON 解析和响应序列化包含进事务。@Transactional 由代理开启和提交或回滚事务，要注意自调用、异常回滚规则以及本地事务不能自动控制远程 HTTP、Redis 和普通 MQ。	Web工程：事务边界、Spring事务全过程
创建订单怎样保证幂等	客户端为同一次操作提供稳定 requestId，服务端将其与用户或租户绑定，数据库建立唯一约束作为并发最终防线；相同 requestId 重试时返回第一次结果。只做先查后写存在并发窗口，Redis 锁也不能替代数据库唯一约束。	Web工程：创建接口幂等
数据库成功但 MQ 发送失败怎么办	不能把数据库和普通 MQ 当成一个本地事务。可将订单与 Outbox 事件在同一数据库事务写入，再由投递器重试发送，或者使用中间件事务消息。投递确认与状态更新之间仍可能重复，因此消费者也必须按事件 ID 幂等。	Web工程：数据库与消息一致性、分布式事务
统一异常和统一返回为什么重要	全局异常处理将参数、业务、下游和未知异常转换成稳定 HTTP 状态与业务错误码，让客户端、网关和监控正确理解结果；内部日志保留 traceId 和堆栈，外部响应不泄露 SQL、类名和敏感信息。不能把所有错误都包装成 HTTP 200。	Web工程：统一错误、全局异常处理
traceId 为什么要在 finally 中清理	Tomcat 工作线程会被线程池复用，MDC 基于线程上下文保存 traceId；请求结束后不清理，下一个请求复用同一线程时可能继承旧 traceId，造成日志串号。	Web工程：traceId与日志
下游调用为什么必须有超时，重试有什么风险	无超时会让 Tomcat 线程和连接池持续等待，最终入口线程耗尽并形成级联故障。重试只能用于可重试、幂等的短暂失败，并限制次数、退避和总预算；创建订单、扣款等请求盲目重试可能重复执行。	Web工程：超时与重试
Actuator 有什么用	Actuator 是 Spring Boot 的生产可观测和运维端点体系，用来暴露健康检查、指标、环境配置、配置绑定、自动配置条件、线程栈和日志级别等信息。它常用于 K8s 探针、Prometheus 监控、自动配置排查和线上诊断。生产环境必须控制暴露端点和访问权限。	Actuator监控
Liveness 和 Readiness 有什么区别	Liveness 表示进程是否还活着，失败时平台通常重启容器；Readiness 表示应用是否准备好接收流量，失败时平台应该摘除流量但不一定重启。数据库短暂不可用通常影响 Readiness，而不一定影响 Liveness，否则可能导致容器反复重启。	Actuator监控：Health、Liveness、Readiness
Spring Boot部署到Docker要关注什么	不只是把Jar放进JRE镜像，还要验证JDK/Boot版本、非root用户、JVM cgroup资源识别、Heap外预算、配置与Secret、端口监听、Actuator探针、stdout日志、Dump挂载、PID 1信号和优雅停机。	Spring Boot容器化运行原理
Actuator 怎么接 Prometheus	引入 spring-boot-starter-actuator 和 micrometer-registry-prometheus，开放 /actuator/prometheus 端点，Prometheus 定时拉取指标并存成时间序列，Grafana 基于 Prometheus 展示看板和告警。业务指标用 Micrometer 的 Counter、Timer、Gauge 注册。	Actuator监控：Prometheus 和 Grafana
自定义业务指标要注意什么	用 Counter 记录只增计数，例如采集成功数；用 Timer 记录接口或下游耗时；用 Gauge 记录队列长度、连接数等瞬时值。指标 tag 只能放低基数字段，例如系统、状态、接口类型，不能放用户 ID、订单号、患者 ID，否则时间序列爆炸，监控系统压力会很大。	Actuator监控：Micrometer 指标体系
Actuator 有哪些安全风险	/env、/configprops、/beans、/heapdump、/threaddump 可能暴露配置、Token、类结构、内存数据和调用栈。生产环境只暴露 health、info、metrics、prometheus 等必要端点，管理端口走内网，敏感端点必须鉴权，health 细节不要直接对公网展示。	Actuator监控：安全边界
Spring Boot 线上接口慢怎么排查	先用 traceId 定位请求日志，确认慢在应用、数据库、Redis、MQ 还是下游接口；再看线程池、连接池、GC、慢 SQL、锁等待、Actuator 指标和线程栈。不要只看 Controller，要沿请求链路逐层定位。	Spring Boot 从零到生产级掌握、Actuator监控

项目话术

在医疗数据采集平台里，Spring Boot 主要负责快速搭建服务、加载多环境配置、启动内嵌 Tomcat、自动装配 Web、数据源、Redis、监控等基础能力。比如医院接口地址、采集开关、线程池参数会放在配置体系里；服务启动后通过 Actuator 暴露健康检查，便于网关、K8s 或监控系统判断实例是否可用。

常见追问

追问	回答方向	跳转
自动配置为什么不是魔法	说明候选自动配置类、条件注解、BeanDefinition、IOC 创建和默认 Bean 让位机制。	自动配置原理
Starter 为什么能开箱即用	说明 starter 聚合依赖，autoconfigure 提供自动配置，条件注解决定是否生效，配置属性承载外部配置，@ConditionalOnMissingBean 让用户可接管。	自动配置与扩展点全过程、Starter机制
为什么有些自动配置没生效	从 debug=true 或 /actuator/conditions 看条件报告，检查候选类是否加载、是否被 exclude、依赖是否存在、配置项是否满足、是否已有用户 Bean。	自动配置原理
配置解密应该放在哪里	如果要在自动配置读取前生效，适合 EnvironmentPostProcessor；如果放到业务 Service，很多配置绑定和条件判断已经执行完了。	Spring Boot扩展点
当前登录用户参数怎么优雅注入 Controller	可以用 HandlerMethodArgumentResolver，统一从 Header、Token 或上下文解析用户信息，避免每个接口重复解析。	Spring Boot扩展点
为什么配置不要写死在代码里	说明多环境部署、密钥安全、动态调整和配置中心。	配置体系
启动慢怎么排查	先看日志卡在哪个阶段，再区分是配置中心、Bean 创建、WebServer 启动还是 Runner 执行。重点检查构造器、@PostConstruct、初始化方法、数据源连接、外部 HTTP 调用、配置中心、端口占用和启动后预热任务。可以配合 debug=true、Actuator startup、线程栈和耗时日志定位。	启动流程全过程原理：启动慢排查、Actuator监控
事务为什么写在 Service 层	说明业务边界、AOP 代理、连接和回滚规则。	Spring事务

面试回答模板

Spring Boot 我会从工程化和扩展机制角度回答。Spring 提供 IOC、AOP、事务这些基础能力，Boot 通过 Starter 和自动配置把常用场景封装成默认能力。自动配置不是魔法，而是 @EnableAutoConfiguration 导入候选配置类，再通过条件注解决定是否注册默认 Bean，最终仍由 Spring IOC 创建 Bean。项目里我会把公共客户端、线程池、健康检查、指标、配置绑定沉淀成 Starter，并通过 @ConditionalOnMissingBean 尊重业务自定义。

深度验收跳转

如果面试官继续追问“你说的这些到底怎么发生”，不要在本页死背长答案，直接回到 Spring Boot 从零到精通验收清单 按阶段复盘：

• 启动流程：从 main 方法到端口监听成功。
• 自动配置：候选类、Boot 2/Boot 3 声明差异、条件注解、BeanDefinition、IOC 创建。
• 配置体系：PropertySource、Environment、Binder、Profile、优先级和 Actuator 排查。
• 扩展点：配置解密、动态注册 Bean、Bean 增强、启动后预热、健康检查、指标、失败诊断。
• 商业落地：医疗采集客户端 Starter、统一 Web 能力、线上接口慢排查。

本章小结

Spring Boot 面试页负责整理“怎么答”。自动配置为什么生效、配置为什么能绑定、Starter 为什么能开箱即用、内嵌 Tomcat 为什么能启动，都要跳到知识点页看原理、流程图、Demo 和排查方式。