简介面向架构师与后端开发人员的 Spring Boot 面试专题资料以问答形式整理了 33 道高频面试题及参考答案覆盖自动配置原理、核心功能、常用 Starter、YAML 配置、监控与项目创建等关键知识块。资源为单个 docx 文档压缩包仅 25KB轻量便携便于面试前集中查阅或作为技术点复盘清单。目前已有 318 人浏览学习是不少开发者备考 Spring Boot 岗位的实用参考。内容从基本概念、优点到实际运行方式均有展开例如内嵌 Tomcat 的独立启动、Fat Jar 打包、DevTools 热重载、Actuator 运行时监控等均给出明确解答同时还包含 JavaConfig、Spring Initializer、ActiveMQ 集成等易考点可帮助读者系统梳理知识脉络快速定位面试中常见问题的答题要点与扩展思路对架构师面试及技术进阶均有实际参考价值。1. 架构师面试题里的Spring Boot专题33道题背完不等于能过面试我见过不少准备架构师岗的开发者拿着一份类似“Spring Boot面试专题及答案33题”的资料从头背到尾结果真到面试现场被一句“你项目里遇到过自动配置失效吗”问得接不上话。问题不在于背题本身而在于这类专题文档给的是“答案”不是“答法”它告诉你该说什么没告诉你面试官为什么这么问、追问往哪个方向追、你该怎么组织自己的项目经验去接话。这份专题真正有用的用法是当一张考点地图——把 Spring Boot 的核心机制拆成可复习的模块再配合自己的二次封装实践去回答。适合谁工作三五年、代码写得熟但讲不清设计依据的开发者已经能答出概念、但希望答出“架构师感”的候选人。这篇文章就按这个目标把 33 题背后的知识点拆开、补上参数与坑给你一条能照着复习的路线。2. 先从根上立住自动配置与启动流程是Spring Boot面试的第一道分水岭2.1 自动配置机制从EnableAutoConfiguration到条件注解的完整链路架构师面试里自动配置是必问题。最常见的问法不是“什么是自动配置”而是“你觉得 Spring Boot 是怎么做到引入一个 starter 就能用的”。这个问题的标准深度应该是能说出 SpringBootApplication 是一个组合注解包含 SpringBootConfiguration、EnableAutoConfiguration、ComponentScan 三部分还能进一步说出 EnableAutoConfiguration 通过 Import(AutoConfigurationImportSelector.class) 导入一批自动配置类再用 ConditionalOnClass、ConditionalOnMissingBean 等条件注解决定哪些配置生效。我用一个最小自定义自动配置类来说明这套机制// 自定义自动配置类模拟 starter 的装配过程 AutoConfiguration ConditionalOnClass(name com.example.SomeClient) // 类路径存在该类型才装配 EnableConfigurationProperties(SomeProperties.class) public class SomeAutoConfiguration { private final SomeProperties properties; public SomeAutoConfiguration(SomeProperties properties) { this.properties properties; } Bean ConditionalOnMissingBean // 容器里已有同类型 Bean 时不重复创建 public SomeClient someClient() { return new SomeClient(properties.getUrl(), properties.getTimeout()); } }上面的类需要在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里声明一行全限定类名Spring Boot 启动时才会扫描到它。注意 Spring Boot 2.7 之前这个名单是写在spring.factories里的之后迁移到了AutoConfiguration.imports这是面试里非常爱挖的版本差异点。回答时先讲链路SpringBootApplication - EnableAutoConfiguration - AutoConfigurationImportSelector - 读取 imports 文件 - 逐一按条件装配。条件注解是这里的核心参数ConditionalOnClass控制依赖存在性ConditionalOnMissingBean控制不覆盖用户自定义的 BeanConditionalOnProperty控制开关。面试官通常会在你答完后追问“如果用户自己定义了一个同类型 Bean 会怎样”这时候答出ConditionalOnMissingBean是保护机制、用户定义优先才算是真的理解而不是背词。2.2 启动流程从SpringApplication到内嵌容器的九个关键节点另一道高频题是“说一说 Spring Boot 的启动流程”。很多人只会说“调用 SpringApplication.run() 就启动了”这在架构师面里是不够的。合理答法是按阶段拆先创建 SpringApplication 实例推断应用类型是 Servlet 还是响应式加载ApplicationContextInitializer和ApplicationListener然后调用 run 方法启动计时广播 starting 事件接着准备 Environment解析命令行参数、系统属性、配置文件创建 ApplicationContext 并 prepareContext最后 refreshContext 进入 Spring 容器刷新流程内嵌 Tomcat/Undertow 就在这一阶段启动容器刷新完成后调用ApplicationRunner或CommandLineRunner做业务初始化。我可以贴一段用来验证启动顺序的代码Component public class StartupOrderRunner implements ApplicationRunner { private static final Logger log LoggerFactory.getLogger(StartupOrderRunner.class); Override public void run(ApplicationArguments args) { // 这个方法在容器刷新完成、WebServer 启动之后才执行 log.info(ApplicationRunner executed after context refresh); log.info(non-option args{}, args.getNonOptionArgs()); // 可以用来确认某些 Bean 是否已经完整初始化 if (args.containsOption(check)) { // 传 --check 参数时做一次依赖可用性自检 ApplicationContext context SpringContextHolder.getContext(); log.info(bean count{}, context.getBeanDefinitionCount()); } } }启动流程题的关键参数主要在application.properties里spring.main.web-application-typenone可以关闭 Web 容器spring.mvc.servlet.load-on-startup控制 DispatcherServlet 的初始化时机spring.main.lazy-initializationtrue会把所有 Bean 变成懒加载显著影响首启速度但会把启动报错挪到第一次调用时。面试官追问“怎么判断启动到哪一步了”时可以答 Actuator 的/actuator/startup端点配合spring-boot-starter-actuator开启启动阶段记录能拿到每个 Bean 创建的耗时排序。这套答法的价值在于你既展示了源码级理解又带了排查参数是典型的架构师视角回复。3. 把33题拆成五个必考板块每个板块的考点与一套可复用的答法3.1 配置体系配置优先级与ConfigurationProperties的边界Spring Boot 的配置题几乎每次面试都会出现常见的问题包括“多个配置文件同时存在时谁生效”“Value 和 ConfigurationProperties 怎么选”。先说优先级从高到低大致是命令行参数、Java System 属性、OS 环境变量、application-{profile}.yml、application.yml、classpath 内部的默认配置。这个顺序不能只背结论要能举例上线时临时改端口为什么用--server.port8081而不是改配置文件因为命令行优先级最高java -jar app.jar --server.port8081可以直接覆盖 yml 里的值。多环境配置是这样的# application.yml 主配置 spring: profiles: active: dev datasource: url: jdbc:mysql://localhost:3306/orders username: root password: root --- # 下面是 dev 环境覆盖段 spring: config: activate: on-profile: dev datasource: url: jdbc:mysql://dev-host:3306/orders username: dev_user password: dev_pass注意 Spring Boot 2.4 之后spring.profiles的激活写法变成了spring.config.activate.on-profile多文档块里用---分隔。面试里追问“bootstrap.yml 和 application.yml 的区别”时要指出 bootstrap.yml 是 Spring Cloud 体系里的概念用于从配置中心拉取配置Spring Boot 2.4 后需要额外引入spring-cloud-starter-bootstrap才会加载它这和纯 Spring Boot 项目的配置加载是两回事。ConfigurationProperties和Value的边界则是前者适合一组配置映射成一个对象、支持类型安全校验和Validated后者适合单个值的快速注入但写法上Value(${app.name:default})要自己处理默认值。架构师面的加分答法是补一句“配置类要放在能被主启动类扫描到的地方否则不生效”这是最常见的踩坑点。3.2 Web层内嵌容器切换与DispatcherServlet自动注册Spring Boot 的 Web 题通常会从“默认内嵌 Tomcat怎么换成 Undertow”这类切入口来考。切换容器的常见做法是先排除 Tomcat 依赖再加入目标容器依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency同时要在配置里关掉 Tomcat 相关的自动配置类否则检测到类路径冲突可能启动报错。关于 DispatcherServletSpring Boot 自动注册它的路径是/可以通过spring.mvc.servlet.path/api/*修改前缀。这里有一个容易被追问的点为什么改了容器后有些 Web 特性不生效。原因在于不同容器对异步请求、WebSocket、静态资源处理的 SPI 实现不一样比如 Undertow 对某些过滤器的顺序表现和 Tomcat 不同。面试官问“线上接口偶现慢请求”时可以结合容器线程池参数回答Tomcat 的server.tomcat.threads.max200、server.tomcat.accept-count100Undertow 则是server.undertow.threads.io与server.undertow.threads.worker。这类参数不需要精确背出默认值但要说清楚各自线程模型差异Tomcat 是传统阻塞 IO 加线程池Undertow 是 IO 线程和 worker 线程分离这在长连接场景下表现不同。3.3 数据访问连接池参数、多数据源与事务失效边界数据访问题里HikariCP 的配置和事务是两大核心。Spring Boot 2.x 默认使用 HikariCP常见配置是spring: datasource: hikari: # 连接池最大连接数默认10高并发写库场景可调大 maximum-pool-size: 20 # 最小空闲连接数 minimum-idle: 5 # 连接存活时间默认1800000毫秒 max-lifetime: 1800000 # 获取连接超时时间默认30000毫秒 connection-timeout: 30000 # 连接只读与否主从分离时从库设true read-only: false面试官追问“连接池参数怎么定”时不要背“默认10”而是说“看数据库 max_connections 与业务 QPS预留 buffer同时要配合慢查询日志判断连接是池不够还是 SQL 慢”。多数据源的题更常出现在架构师岗配置两个 DataSource需要手动声明Primary否则注入时会因容器里存在多个同类型 Bean 而报 NoUniqueBeanDefinitionException。事务边界题的高频考法是“哪些场景下 Transactional 会失效”我在这一章的避坑位置会详细展开这里只提示一个关键答法Transactional默认只在 RuntimeException 和 Error 下回滚受检异常不会回滚这是最容易被忽略的默认参数并且自调用this.method()不走代理事务注解完全不生效。面试答到“事务要通过代理对象调用才有效”这个层面才算答到点上。3.4 Bean生命周期与扩展点从BeanPostProcessor到AOP代理的顺序Bean 生命周期是 Spring 面试的常青树架构师面里会考得更细不仅要说出PostConstruct、afterPropertiesSet()、init-method的顺序还要能处理“这些回调在 AOP 代理生效前还是生效后执行”的问题。我先给一个可运行的最小验证代码Component public class LifecycleDemoBean implements InitializingBean, DisposableBean { private static final Logger log LoggerFactory.getLogger(LifecycleDemoBean.class); public LifecycleDemoBean() { log.info(1. constructor); } PostConstruct public void postConstruct() { log.info(2. PostConstruct); } Override public void afterPropertiesSet() { log.info(3. InitializingBean.afterPropertiesSet); } Bean(initMethod customInit) public void customInit() { log.info(4. custom init method); } PreDestroy public void preDestroy() { log.info(5. PreDestroy); } Override public void destroy() { log.info(6. DisposableBean.destroy); } }跑这段代码打出的日志顺序是构造函数 - 注入依赖 - PostConstruct - afterPropertiesSet - 自定义 init-method - Bean 就绪。这里有一个区分点PostConstruct和afterPropertiesSet都在属性注入完成后执行但BeanPostProcessor.postProcessBeforeInitialization比它们都早AOP 代理的创建则发生在postProcessAfterInitialization阶段。也就是说如果你的 Bean 被切面增强那么你在PostConstruct里拿到的this是原生对象而不是代理对象调用被拦截的方法不会走切面逻辑。这是很多人在面试现场答不出的细节但只要你自己的项目里写过切面做操作日志就能自然说出这个顺序。答题时把扩展点串成一句话构造 - 属性注入 - BeanPostProcessor 前置处理 - 初始化回调 - BeanPostProcessor 后置处理 - AOP 代理生成 - 使用 - 销毁回调。3.5 监控与调优Actuator端点与线程池参数的“加分回答”Spring Boot 面试题里调优类问题越来越常见。问法一般是“你的服务线上怎么监控”“QPS 上不去先看什么”。标准答法是引入spring-boot-starter-actuator暴露关键端点。需要记忆的参数表大致是端点默认是否暴露用途/actuator/health是存活与健康检查可配合组件状态/actuator/info是自定义构建信息/actuator/metrics否JVM、内存、线程、HTTP 指标/actuator/loggers否运行时调整日志级别/actuator/threaddump否线程快照排查死锁与阻塞/actuator/heapdump否堆快照排查内存泄漏只用一句话比分更合理比如答的是“通过 metrics 看 Tomcat 线程活跃数是否打满、通过 threaddump 查 BLOCKED 线程、通过 heapdump 做离线分析”。线程池参数这里要能说出 Tomcat 默认最大线程数 200、默认 accept-count 100以及server.tomcat.max-connections8192与线程数的差异匹配。更进阶一点可以说“设置合理的等待队列长度不能让请求直接拒绝也不能无限堆积一般按压测结果调整”。这类回答展示的是你解决过真实问题而不是背参数表。最后可以补一句“调优先看监控再动参数不要上来就改线程池先确认 QPS 瓶颈是在 Tomcat 线程、数据库连接池还是下游接口”这句话本身就是架构师思维。4. 从背答案到讲答案把33题整理成能现场输出的一页纸4.1 面试官真正听的是决策依据不是背诵很多人的复习方式是把答案抄进笔记然后反复读。问题是面试官问的是“你项目里为什么用 Spring Boot 而不是 Spring MVC”你回答“Spring Boot 简化配置、内嵌容器、生态好”他接下来就会问“简化了什么、内嵌容器解决了什么、你为此付出了什么代价”。这时候背诵的答案会迅速露馅。我的建议是给每一个知识点配一个“决策依据”维度也就是当时做技术选型时取舍的原因。比如为什么选择 Undertow 而不是默认的 Tomcat真实的决策依据可能是某订单服务长连接较多、需要低内存占用而不是“网上说 Undertow 性能好”。这套说法讲给面试官他感受到的是你做过选型、踩过坑而不是看了篇博客。复习时每道题只保留三个要素结论、结论成立的前提、不成立时的反例。前提和反例才是拉开差距的地方。4.2 一页纸卡片把33题压缩成可复述的分钟级复习模板33 题全背不现实我比较习惯的做法是把每题压缩成一张卡片格式固定如下题目内嵌容器切换的代价是什么 背景某订单服务原用 Tomcat因长连接与内存占用改为 Undertow 结论降低约 20% 内存占用容器线程模型从阻塞IO变为IO/Worker分离 前提应用以长连接、低并发、IO密集为主静态资源较少 参数server.undertow.threads.io4, server.undertow.threads.worker32 反例如果应用是短连接高并发Undertow 的线程模型优势会缩小上面这套结构可以套用到绝大多数题目格式上就是“题目 - 背景 - 结论 - 前提 - 参数 - 反例”。准备时不用写长文每个字段一两句话即可。面试前半小时快速过一遍卡片的“反例”列这通常就是面试官追问的方向。我自己的经验是这份卡片不要超过一页纸写完以后要能做到闭眼复述“前提”和“反例”这两个字段。如果某个知识点的反例写不出来说明你还没真正理解它这部分值得回炉。实际面试中这一套结构通常能支撑你讲满三五分钟而且不会跑偏。5. 避坑指南背了答案却翻车的五个典型场景5.1 版本混淆把 Spring Boot 2.3 的答案答到 2.7 的题上现象面试官问自动配置加载机制回答“Spring Boot 通过 spring.factories 读取自动配置类”这是一个明显的版本错位。Spring Boot 2.7 之后自动配置名单迁移到了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports2.4 之后配置文件的加载方式也变了。原因很多复习资料停留在早期版本背题时没有同步项目的实际版本。解决开口前先说清楚“我基于 Spring Boot 2.7.x 回答它的机制是…”既给自己划定边界也展示版本意识。如果面试官追问旧版本差异再补一句“2.4 之前是 spring.factories2.7 之后是 AutoConfiguration.imports”。5.2 自动配置排除答不出 exclude 与 excludeName 的区别现象面试官问“你线上不想启用某个自动配置怎么办”候选人立刻答出SpringBootApplication(exclude XxxAutoConfiguration.class)。这没错但追问“exclude 和 excludeName 有什么区别”就卡住。原因只背了用法没注意 exclude 传的是类excludeName 传的是类名字符串后者主要用在反射场景或配置文件的spring.autoconfigure.exclude属性。解决回答时要把三个排除通道一起说注解 exclude、配置文件spring.autoconfigure.exclude、以及EnableAutoConfiguration上的 exclude。记住一个原则排除机制是给“确定不需要”的自动配置用的不是给“暂时报错”的配置用的后者要优先查条件注解为什么不生效。5.3 Bean生命周期题答不全回调顺序现象被问到“Bean 创建过程中有哪些扩展点”只能挨个报名字报完就断。原因把生命周期当成名词列表在背没理解每一步的触发条件和用途。解决先画一条线构造 - 属性注入 - BeanPostProcessor 前置 - 初始化 - BeanPostProcessor 后置 - 代理生成。然后把每个扩展点对应到实际场景BeanNameAware拿 Bean 名字、ApplicationContextAware拿容器、PostConstruct做资源初始化、InitializingBean做依赖校验、PreDestroy释放资源。面试时按“先讲线再讲点每个点带一个使用场景”的次序讲会比报菜名好很多。5.4 事务失效场景只答出“自调用”一条现象面试官问“哪些场景会导致 Transactional 失效”候选人只说了“同类内部方法调用不走代理”。原因这是网上最常见的答案其他失效场景没有被归拢。解决按三层组织答案第一层是 Bean 没有被 Spring 管理比如new出来的对象第二层是方法不是 public切面无法织入第三层是异常被吞掉事务感知不到回滚信号。最后补上“默认只回滚 RuntimeException受检异常需要 rollbackFor 指定”。按这三层记即使漏一条也能从整体结构推出来。5.5 参数类题目硬背数值背了就忘现象问 Tomcat 默认线程数是多少记住了 200问 HikariCP 默认最大连接数记住了 10再问 max-lifetime 默认值卡住。原因把参数当成纯记忆任务没有关联到“在哪里能查到”和“为什么是这个值”。解决面试时不硬背所有数值改成说“我记得大概是这个数量级具体要看运行环境一般通过 actuator 暴露的指标来确认”。这句话在架构师面试里反而是加分项它说明你有监控意识而不是靠猜。复习时每个参数只需要记住“默认值 调大后的代价 调小后的代价”即可比如 HikariCP 的 max-lifetime 默认 30 分钟调大可能导致数据库端连接被回收后客户端还在用旧连接。6. 面试题不是终点用源码验证和自研starter把33题变成能力证明拿到任何一份 Spring Boot 面试题我的习惯不是去背答案而是把每道题映射到源码里的一个类或方法上。这样做一次印象远比读十遍答案深刻。你可以选几个核心入口做源码定位自动配置题对应AutoConfigurationImportSelector看它怎么读取AutoConfiguration.imports启动流程题对应SpringApplication.run()逐行看它调用了哪些 listenerWeb 容器题对应ServletWebServerFactoryAutoConfiguration看它如何条件装配 Tomcat、Jetty、Undertow。每个类花二十分钟读完再回到题目本身你会发现自己能讲出比标准答案更具体的细节。更进一步可以尝试手写一个最小 starter包含一个自动配置类、一个属性类、一个AutoConfiguration.imports文件。做完之后你会理解为什么ConditionalOnMissingBean重要为什么 starter 的包名要尽量不与业务代码重叠为什么配置项要带统一前缀。这个动手过程会把面试题里的知识点变成肌肉记忆比反复看文档有用得多。我自己的习惯是在每次面试准备时挑三道题做源码验证再用卡片方式输出所以我拿到题的第一件事永远是问三个问题基于什么版本、适用什么场景、不适用时怎么办。这三步走完面试题对你的价值就远远不只是“背完能答”而是一次系统性的技术复盘。希望这份梳理能帮到你顺着这条思路把每一道题都变成你真正讲得出口的东西。本文还有配套的精品资源点击获取