1. 自动装配面试官必问的第一题底层到底在干什么每次面SpringBoot十个面试官里有九个会问同一个问题“你用过SpringBoot那你知道它为什么引入一个依赖就能直接用吗”很多人能答出“自动装配”四个字但再往深走就卡壳了。这一题过不过基本决定了后面面试的基调因为它是SpringBoot全部设计理念的集中体现。1.1 SpringBootApplication 是怎么被设计成一枚“三合一”注解的先看最表面的入口类所有SpringBoot项目都有一个带SpringBootApplication注解的启动类。很多人没去点开过这个注解的定义它其实是个组合注解一眼看全Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) Documented Inherited SpringBootConfiguration EnableAutoConfiguration ComponentScan(excludeFilters { Filter(type FilterType.CUSTOM, classes TypeExcludeFilter.class), Filter(type FilterType.CUSTOM, classes AutoConfigurationExcludeFilter.class) }) public interface SpringBootApplication { }拆开来看SpringBootConfiguration本质就是Configuration让启动类本身成为一个配置类ComponentScan负责把启动类所在包及其子包下的Component、Service、Controller、Repository全部扫进容器。真正让它区别于普通Spring应用的是EnableAutoConfiguration也就是自动装配的总开关。面试时我建议你这样答SpringBootApplication同时承担了配置类声明、包扫描范围、自动装配开关三件事其中自动装配是它的灵魂也是SpringBoot能简化配置的根本原因。1.2 从 spring.factories 到 AutoConfiguration.imports 的演变面试官如果继续追问“自动装配具体是怎么执行的”就到了区分熟手和新手的节点。早期SpringBoot版本里所有自动配置类路径都写在META-INF/spring.factories文件中键是org.springframework.boot.autoconfigure.EnableAutoConfiguration值是长长一串配置类全类名。但spring.factories有个问题它不区分自动配置和普通组件文件内容越堆越杂而且SpringBoot 2.7之后官方逐步废弃了这种加载方式改成了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件。3.x版本则直接移除了对spring.factories中自动配置加载的支持。这就是很多人升级到SpringBoot 3.x之后发现原本好用的starter“失效”了的技术背景。如果你在面试时说“自动装配就是读spring.factories”那基本就暴露了你没有经历过版本升级、也没有读过新版框架源码的老状态。我自己在梳理这个机制时习惯把它分成三步来理解EnableAutoConfiguration通过Import(AutoConfigurationImportSelector.class)触发导入逻辑AutoConfigurationImportSelector去加载AutoConfiguration.imports文件里的全部候选配置类候选类逐个经过Conditional条件判断只有条件满足的才会被真正实例化并注册到容器。1.3 条件注解自动装配的“开关”机制这一步是整个机制的精华。框架收集了一堆候选配置类但不可能全都启用。比如RedisAutoConfiguration只有在classpath里存在RedisOperations这个类时才会生效DataSourceAutoConfiguration只有在存在DataSource相关类时才会生效。这些都是靠ConditionalOnClass这类条件注解控制的。常用的条件注解有这么几个我列个表方便你记忆注解作用典型使用场景ConditionalOnClassclasspath存在指定类时生效依赖引入了某个starterConditionalOnMissingBean容器中没有指定Bean时生效允许开发者自定义覆盖默认配置ConditionalOnProperty配置项满足指定值时才生效通过配置开关控制功能ConditionalOnBean容器中存在指定Bean时生效依赖其他Bean先被注册ConditionalOnExpressionSpEL表达式为true时生效复杂组合条件面试追问到这里你可以补一句自己写starter时的心得自定义自动配置类一定要配合ConditionalOnMissingBean否则用户想覆盖你的默认Bean都没机会这属于基本的可扩展性素养。2. SpringApplication.run() 启动流程里隐藏的面试考点如果说自动装配回答的是“SpringBoot怎么知道要配什么”那启动流程回答的就是“SpringBoot到底是怎么把应用拉起来的”。面试官喜欢拿“启动过程经历了哪些阶段”做深度追问而且这个问题没有标准答案长度你能讲多深就能看出你平时看代码看到了哪一层。2.1 启动的完整阶段拆解SpringApplication.run()表面看只是传个启动类进去然后执行实际上内部逻辑庞杂我按个人刷源码时的理解总结成下面几个阶段首先是准备阶段。通过WebApplicationType.deduceFromClasspath()判断当前应用是Servlet还是Reactive类型然后加载META-INF/spring.factories里的ApplicationContextInitializer和ApplicationListener实现这一步很多人容易漏掉但面试官听你说出来会很加分。接着进入SpringApplicationRunListeners的启动回调阶段。框架会广播ApplicationStartingEvent、ApplicationEnvironmentPreparedEvent等事件保证在容器还没创建时就能处理日志、配置等基础能力。然后是环境准备。这一步会做两件事读取application.properties/yml、解析命令行参数然后把它们合并成ConfigurableEnvironment过程中会加载spring.profiles.active指定的profile文件。再往后就是核心的容器创建流程了。框架根据应用类型创建对应的ApplicationContextServlet应用是AnnotationConfigServletWebServerApplicationContext注册启动类为配置类然后执行refresh()方法。这个refresh()是Spring老框架的东西AbstractApplicationContext里的模板方法bean工厂创建、bean注册、bean初始化都在这里完成。最后是afterRefresh()阶段打印启动耗时然后回调ApplicationRunner和CommandLineRunner完成整个启动动作。2.2 被高频追问的两个扩展点启动流程这块面试官特别爱问的扩展点有两个第一个是ApplicationRunner和CommandLineRunner的区别。两者都是应用启动完成后要执行的逻辑但参数不一样。CommandLineRunner拿到的是原始字符串数组而ApplicationRunner拿到的是解析后的ApplicationArguments这个对象里区分了option参数和非option参数。实际开发里如果要做启动预热、初始化缓存优先选ApplicationRunner因为能利用参数名做安全获取。第二个是banner的输出时机。很多同学只在意怎么把启动时那个字符画换成自己生成的图案没去想它为什么能打印出来。实际上banner是将BannerPrinter注册为ApplicationListener监听ApplicationEnvironmentPreparedEvent事件在环境准备好的那一刻打印的。这个逻辑藏在SpringApplication的初始化流程里知道这个细节面试官问你“banner能不能在日志框架之前打印”你就不会懵了。2.3 启动变慢和启动失败的排查思路平时我在生产环境排查过几次应用启动慢的问题这里分享一个通用排查路径先看日志里Starting和Started两个时间戳之间的耗时差距如果超过预期再去翻refresh()阶段用了多久。常见的原因不外乎四类初始化Bean时调用外部接口超时比如在ApplicationRunner里做远程预热懒加载没开大量Bean在启动时一次性创建PostConstruct里做了大量IO或递归计算数据库连接池初始化阻塞比如配置了连接池但网络不通导致建连超时。另外有个坑是启动类放错包路径。ComponentScan默认扫启动类所在包如果其他模块的包名不在启动类包路径下Bean就不会被注册日志也不会报错只是功能异常这种问题在小团队里特别常见。排查时先确认Application类的package是不是所有业务模块的父包这个细节简单但极其有效。3. 配置加载优先级与多环境管理必拿分的高频区SpringBoot的配置体系在面试中属于知识点密集、但不难掌握的部分。面试官问的时候一般会从“配置文件优先级”切入然后顺着问多环境部署怎么处理。这块答好了能给面试官留下“基本功扎实”的印象。3.1 配置项的加载优先级SpringBoot的配置来源很多我用一句话总结命令行参数最厉害Java系统属性其次OS环境变量第三然后是配置文件中的内容。详细优先级从高到低是这样命令行参数java -jar app.jar --server.port8081SPRING_APPLICATION_JSON里的内嵌JSONServletConfig/ServletContext参数JNDI属性Java系统属性System.getProperties()OS环境变量application-{profile}.properties/yml带profile的配置文件application.properties/yml主配置文件PropertySource加载的配置。这个顺序要能背下来并且要能解释其中的设计思路。命令行参数最高是因为部署阶段经常需要临时覆盖配置例如同一套Jar包在测试环境用8080端口在预发环境用8081如果写死在配置文件里就得维护多份不如启动时传参覆盖。实际开发中我推荐的做法是基础配置和默认值放在application.yml里环境差异配置放在application-dev.yml、application-prod.yml里启动时用--spring.profiles.activeprod指定。敏感信息数据库密码、密钥不要放在配置文件里提交到代码仓库用环境变量或配置中心管理。3.2 profile多环境配置的两种写法SpringBoot里profile选择有两种写法面试把它们区分开会很加分。一种是在配置文件里写spring.profiles.active另一种是在启动命令中加--spring.profiles.activexxx。前者适合默认环境固定、变更不频繁的场景后者适合CI/CD流水线里动态指定。还有一种特殊用法很多人不知道同一个application.yml里可以用---按profile分块书写而不必拆成多个文件。这种方式适合配置量不大、集中收敛的场景server: port: 8080 spring: profiles: active: dev --- spring: config: activate: on-profile: dev server: port: 8080 --- spring: config: activate: on-profile: prod server: port: 9090注意一下SpringBoot 2.4之后spring.profiles和spring.profiles.include的书写位置有调整我把这个变化放在下一节里说因为它跟“版本太高”那类坑紧密相关。3.3 SpringBoot版本升级带来的配置变化热搜词里有“springboot版本太高”这个词我太有共鸣了。SpringBoot 2.4和2.6是两个让很多升级者头疼的版本。2.4开始spring.profiles.active不再允许出现在profile专用的文档块里而且原来spring.profiles属性名改成了spring.config.activate.on-profile还有一个大变化是多了spring.config.import机制配置可以从外部文件导入。如果你在2.3项目里把profile切换写在特定配置块里升级后启动时会报配置加载错误。2.6则开始对循环依赖做严格限制默认禁止循环依赖不允许通过spring.main.allow-circular-referencestrue之外的配置放行。很多老项目用循环依赖用习惯了升级后容器启动直接失败第一反应就是“版本太高了”。我的建议是面试被问到版本相关问题时别笼统说“太高了不好”而是精准指出“2.4改了配置激活语法2.6限制了循环依赖3.x切了Jakarta命名空间且移除了spring.factories自动配置加载”这三条就足够证明你经历过真实升级场景。3.4 自定义配置绑定ConfigurationProperties 还是 Value配置类的最后一块是配置绑定。Value适合简单取单个值ConfigurationProperties适合批量绑定一组有结构的配置。想让ConfigurationProperties生效需要满足两个条件定义属性类并加上注解再用EnableConfigurationProperties或Component把类注册成Bean。我一般这样写Component ConfigurationProperties(prefix wechat) public class WechatProperties { private String appId; private String secret; // getter/setter 省略 }对应的配置项wechat: app-id: wx123456 secret: abcdefg这里有个细节注解绑定默认是relaxed binding就是说配置里的app-id能绑定到Java字段appId上不用一字不差地对应。别再用Value(${wechat.app-id})一条条引了显得处理不了复杂结构。同时ConfigurationProperties还支持Validated做参数校验比如NotBlank、Max这在对接外部系统时能省掉大量手工判断代码。4. 默认用CGLIB代理这件事藏着SpringBoot的设计取向“springboot默认使用cglib代理”是热搜词里比较独特的一个。它看起来像是一个零散的知识点但实际牵涉到AOP代理机制和SpringBoot“约定优于配置”的设计取向。4.1 代理默认值从JDK变成CGLIB的原因先还原一下历史。Spring Framework老版本里proxyTargetClass默认是false也就是Spring AOP默认使用JDK动态代理只为接口生成代理对象。这就导致一个经典问题类没有实现接口时AOP无法织入。SpringBoot从2.x开始把spring.aop.proxy-target-class的默认值改成了true并最终在后续版本里把默认策略固定为CGLIB代理。为什么SpringBoot要这么干因为SpringBoot精神是“拿来就用、少写门槛”若默认走JDK代理你会遇到“ServiceImpl实现接口但多了一层继承关系时又代理不上”的边界状况。反而是CGLIB这种基于子类生成的代理方式对用户要求最低你不用刻意抽象接口普通类也可以直接代理。这也是SpringBoot默认选CGLIB的实用考量——尽量消除框架对代码结构的侵入要求。4.2 CGLIB代理对日常开发的影响知道了这个默认值对编码有什么实际影响第一点是Autowired一个Bean时注入的对象实际上是CGLIB生成的子类所以有些方法用this调用时会绕过代理典型场景就是Transactional自调用失效。代码里同一个类里的方法B调用方法AA上有Transactional但代理只作用在外部入口内部调用走的还是原生this对象事务注解完全不生效。第二点是Async也有同样的毛病自调用场景下异步不生效。这是Spring Boot默认CGLIB代理后最常见的两个陷阱。我处理过几次这种问题排查思路就是把自调用拆开要么把逻辑抽到另一个Bean里面去要么用ApplicationContext.getBean()拿代理对象再调方法。第三点是CGLIB要求被代理的类不能被final修饰。你写一个final的Service类SpringBoot启动时直接抛异常。老代码里有这种写法的话升级SpringBoot后需要去掉final。4.3 内嵌容器与starter机制的同源设计理念CGLIB只是SpringBoot众多“默认设计”之一。它的另外两个核心默认设计就是内嵌容器和starter机制它们共同构成“开箱即用”的开发体验。内嵌容器的设计目标是让应用变成“一个带main方法的独立进程”。传统Spring项目要部署到外部Tomcat里还需要手动构建WAR包而SpringBoot直接在依赖里声明spring-boot-starter-web通过TomcatServletWebServerFactory把Tomcat作为内嵌对象启动打出来的包用java -jar直接运行。这也解释了为什么生产上用SpringBoot部署时连“安装Tomcat”这一步都不存在。starter机制的逻辑也好理解用一组依赖约定把完成任务所需的一揽子库和自动配置绑定在一起。引入spring-boot-starter-data-redis之后你不仅获得了Redis客户端库还同时自动装配了RedisTemplate、连接工厂等配套组件。所以面试里聊starter时别只说“引入依赖很方便”要能把这件事拆成“依赖集合 自动配置类 条件装配”三部分来讲。5. 定时任务与虚拟线程从使用走向源码层的面试加分点聊完框架的骨架设计面试官往往会转向比较实操的问题比如定时任务怎么用、怎么控制线程数量、高并发下有什么隐患。这些内容面试官通常不作为必杀题但答得好会很出彩。5.1 定时任务的开启方式和线程池隐患SpringBoot的定时任务依托于Spring的Scheduled注解使用时有严格的两步启动类或配置类上要加EnableScheduling然后在具体方法上写Scheduled(cron ...)。有个导致定时任务莫名其妙不执行的原因就是忘了EnableScheduling。看起来是个低级错误但在多模块项目里EnableScheduling只放在某个子模块的配置类上而定时任务方法写在另一个模块扫描范围一旦覆盖不到任务就不会被触发且毫无报错。这样加完之后你就要面对一个更重要的问题Spring默认的定时任务调度器是单线程的。换句话说容器里如果注册了10个Scheduled方法它们默认是排队逐个执行的其中一个长时间阻塞会导致其他所有定时任务被卡住。真实线上就出过类似故障一个推送任务调外部API超时十分钟把它后面的所有定时任务都堵死了数据延迟严重。解决办法是要自定义TaskScheduler的线程池大小为3到10之间并设置合理的rejection policy。我通常这样配Bean public TaskScheduler taskScheduler() { ThreadPoolTaskScheduler scheduler new ThreadPoolTaskScheduler(); scheduler.setPoolSize(5); scheduler.setThreadNamePrefix(scheduled-task-); scheduler.setWaitForTasksToCompleteOnShutdown(true); scheduler.setAwaitTerminationSeconds(60); return scheduler; }这里的setWaitForTasksToCompleteOnShutdown(true)的作用是应用停机时等已触发的任务执行完再关容器避免数据写一半就中断。5.2 定时任务的cron表达式里的版本差异Spring的cron表达式跟Linux crontab有个重要区别Spring的cron是6段比Linux多一个秒字段。写法是“秒 分 时 日 月 周”例如0 30 2 * * ?表示每天凌晨2点30分执行。注意不能用*同时描述日和星期要么其中一个用?占位否则会解析失败。这个点很多人会栽我干脆给你一个等价参考表需求表达式说明每天2点执行0 0 2 * * ?秒分时固定日周用?每天上午10:15执行0 15 10 * * ?与上同理周一到周五每5分钟一次0 */5 * * * MON-FRI分钟通配加周范围每月最后一天23:30执行0 30 23 L * ?L表示最后一天每月1日和15日各执行一次0 0 0 1,15 * ?日字段用逗号枚举我是建议把“Spring的cron是6段含秒、且日与周必须有一个写?”这两句话背下来面试时答出来面试官就知道你确实写过而不是背概念。5.3 SpringBoot 3.x里的虚拟线程newvirtualthreadpertaskexecutor热搜词里还冒出一个很新的词条“springboot newvirtualthreadpertaskexecutor”这其实是SpringBoot 3.2为用户提供的一个基于虚拟线程的任务执行器Bean。JDK 21正式支持虚拟线程之后SpringBoot跟进把ThreadPoolTaskExecutor的默认实现换成虚拟线程变成了可能。启用方式很简洁在application.yml里设置spring: threads: virtual: enabled: true设置之后框架注入的TaskExecutor变成了基于Executors.newVirtualThreadPerTaskExecutor()的虚拟线程执行器每次提交任务都新起一个虚拟线程不再复用池化线程。这带来的好处是线程数量不再受操作系统线程上限的硬性限制对高IO并发场景比如网关转发、RPC调用聚合效果立竿见影。但不要以为虚拟线程能解决一切。synchronized锁和受限的CPU密集型计算依然会阻塞载体线程而且如果代码里有ThreadLocal跨任务传递的业务逻辑虚拟线程复用载体线程的行为会导致ThreadLocal值顺着载体线程在多个虚拟线程间串数据。我在实际项目中把虚拟线程用在线程模型简单的API网关层效果稳定但在承载复杂ThreadLocal业务的地方还是保留传统线程池更稳妥。6. 生产监控与面试表达的两点个人心得最后聊两块一是SpringBoot生产监控怎么用二是面试回答时怎么把知识组织得让面试官觉得你“真做过”。6.1 Actuator端点与生产监控的落地SpringBoot自带的生产监控能力是spring-boot-starter-actuator。引入后最常用的端点是/actuator/health和/actuator/info。开发环境里可以开更详细的env、metrics、loggers生产环境中只暴露health和info别把内存、配置、环境变量接口全亮出来这个单子风险太高。微服务治理场景下直接通过HTTP拉取每个实例的状态并不够用通常的做法是结合注册中心做心跳检查或者用采集器定时抓取/actuator/prometheus端点生成监控指标。SpringBoot项目里只要引入micrometer-registry-prometheus再配置management.endpoints.web.exposure.includeprometheus就能在端点上输出Prometheus格式指标这套东西已经是微服务架构里的标配。为了让健康检查反映真实依赖状态我一般自定义健康指示器查询一次数据库、ping一次Redis如果主依赖挂了就返回DOWN上游发现服务不健康后会自动摘除流量。这是线上比较成熟的做法也适合写进项目介绍里作为亮点。6.2 面试表达把知识点拼成一个设计故事说回面试这件事本身。面SpringBoot时面试官真正想看的不只是你记住了什么而是你能不能把记忆碎片组织成逻辑自洽的解释体系。我的经验是讲自动装配时顺着“为什么需要→怎么收集候选类→怎么过滤条件→怎么暴露扩展点”讲下来一个链路串着三个知识点AutoConfiguration.imports的加载机制、Conditional注解体系、ConditionalOnMissingBean的自定义覆盖方法。讲到启动流程时同理从SpringApplication.run()进入把事件监听、环境准备、容器刷新、回调Runner按时间线排开每到一个节点就提一个你实际用过的扩展点。还有一个实操小技巧面试前把SpringBoot和你最近做过的项目做一次映射比如“我这个项目里XXX的耗时就是通过自定义ApplicationRunner预热的当时发现启动慢之后做了延迟加载优化”。项目里真实踩过的坑永远比概念解释更有说服力。这部分建议平时就积累不要临时抱佛脚。最后给正准备去面试的朋友一个建议SpringBoot的知识点体量很大但真正会被深入追问的从来不是“SpringBoot有哪些注解”这种清单式问题而是“它为什么这样设计”。试着用框架设计者的视角重新审视你每天写的启动类、配置文件和starter依赖你的回答层次自然会和只会背概念的人拉开差距。