Spring Boot 面试题
作者 Aaron Cao · 更新于
预计会被问到自动配置与 starter、依赖注入与 bean 作用域、profile 与外部化配置、Spring Data JPA、REST 控制器与异常处理、测试切片，以及 Actuator。高级岗位的面试还会加入事务边界、缓存，以及服务在重启前后的行为表现。
面试官会问哪些关于自动配置与 starter 的问题？
你可能每天都在用 Spring Boot，却从没读过它的启动日志——面试官深知这一点，所以常从这里切入。这部分考察你是真正理解这个框架，还是只会用它的默认配置。
@SpringBootApplication实际上组合了什么？去掉其中一部分会导致什么问题？- 自动配置如何决定要配置什么？条件注解在其中起什么作用？
- 什么是 starter？除了依赖之外，它里面还有什么？
- 如何覆盖或禁用某个特定的自动配置？
- 内嵌服务器从何而来？你会如何替换它？
好的回答会把机制和你实际做过的事联系起来：你排除过的某个 bean、你替换过的某个 starter，或是你通过条件评估报告排查过的一次启动失败。
还会涉及哪些核心容器与数据相关的问题？
- 依赖注入。构造器注入与字段注入的区别、为什么构造器注入更受青睐，以及当同一类型有两个候选 bean 时如何解决冲突。
- Bean 生命周期与作用域。为什么单例是默认作用域、什么时候 request 或 prototype 作用域才是正确选择，以及是什么让单例 bean 在共享时变得不安全。
- 配置。属性优先级、按环境划分的 profile，以及
@ConfigurationProperties与零散的值注入之间的区别。 - Spring Data JPA。派生查询方法、N 加 1 问题、懒加载与立即加载的区别，以及何时该改用原生查询。
- 事务。
@Transactional代理实际拦截的是什么、为什么自调用会悄悄跳过事务，以及回滚规则如何与受检异常配合工作。
事务代理问题是最常见的翻车点，即使是自信满满的回答也常在这里露馅，所以要准备好解释代理边界，而不只是说出注解的名字。
如何讨论 REST 设计、测试与运维？
除了容器本身，面试官还想了解那些会在生产环境中体现出来的部分。在 Web 层：状态码的选择、校验，以及用 @ControllerAdvice 做集中式错误处理，而不是在每个控制器里都写 try-catch。在测试方面：完整的 @SpringBootTest 和诸如 Web 层测试这样的切片测试之间的区别，以及为什么为了一个控制器测试就启动整个上下文是个低效的习惯。在运维方面：Actuator 暴露了哪些内容、哪些端点绝不能公开，以及健康检查如何为部署提供依据。
设想一位在物流公司面试中级岗位的后端工程师。她被问到，为什么一个定时任务有时会写入不完整的数据。她没有靠猜测，而是逐步梳理事务边界，指出该任务在自身内部调用了一个事务方法，并解释了导致该调用被跳过的代理行为。面试官随即直接进入了 offer 环节，因为这个回答体现的是排查问题的习惯，而不是死记硬背的定义。
其他语言与框架的题库汇总在 题库 页面下。
该如何练习？实时助手在其中扮演什么角色？
先把自己所在服务的启动日志通读一遍，做到能够讲清楚每一步。然后要大声练习，因为能否在四十秒内把一个概念解释清楚，往往决定了这些面试轮次的成败。「/mock-interview」页面上的 AI 面试官，能够问出你自己想不到的追问。
在语音视频面试过程中，SubcueAI 会转写面试官提出的问题，并在你这一侧给出建议的回答结构——可以是 macOS 与 Windows 上的桌面悬浮窗，也可以是 Chromium 浏览器扩展的侧边栏。不会有任何会议机器人加入通话，也不会向会议页面注入任何内容。诚实地说，编程环节是明确的边界：如果流程转向屏幕监控或有监考的平台，实时协助就不在范围内；如果你共享了屏幕，屏幕上的一切都会被看到。