Spring 面试题这东西圈里一直有个说法考的不是你会不会背而是看你到底用没用过。我在一线做后端开发这些年面试别人和被别人面加在一起上百场最深的感觉是——Spring 的知识点从来不是孤立存在的面试官问的问题背后永远跟着一个“为什么”和一个“你项目里踩过什么坑”。最近的搜索热度也能看出来除了最基础的 spring 概念大家搜得最多的是 spring boot、spring三级缓存、spring ai、spring cloud alibaba、spring security、bean生命周期、手写 spring——这些恰恰是这些年面试真题里最常出现的考点。这篇内容我打算按这套热度地图走一遍把 Spring 面试中的高频考点、每个考点背后的原理、面试官真正想听到的回答路径以及我实际复习和带人过程中总结的经验都展开讲透。无论你是刚准备校招的应届生还是想跳槽的三年经验后端这篇都值得当作一份复习提纲来用。1. Spring 面试题的考点地图——先搞清楚面试官在考什么1.1 考点不是散点而是一条连贯的知识链很多人准备 Spring 面试是照着题库一条条背的什么是 IoC什么是 AOPBean 生命周期是什么事务传播行为有哪几种背完觉得自己都会一到面试现场被追问一句“那你项目里哪里用到了反射”就直接卡壳。问题出在把 Spring 学成了一个个孤立的点而面试官心中其实有一条清晰的知识链容器如何管理对象 → 对象之间如何协作 → 对象在特殊场景下如何处理代理、事务、安全→ 如何快速开发和部署Spring Boot→ 如何支撑大规模分布式系统Spring Cloud。这条链上的每个环节都对应一类核心考题而面试官追问的永远是“链与链之间的衔接点”。比如问你“什么是 IoC 容器”下一句往往就是“Bean 是怎么被创建出来的”“创建过程中如果出现循环依赖怎么办”“这个 Bean 的代理对象是谁创建的”“代理对象和普通对象有什么区别”。这些问题一环扣一环任何一环含糊都会露馅。所以我一直建议准备 Spring 面试以 Bean 从定义到销毁的完整生命周期为主线来组织知识体系比按题目分类背题有效得多。1.2 近年面试题的变化从“背定义”到“考实战”前些年的 Spring 面试题风格更偏概念背诵说出 IoC 的四种注入方式、AOP 的五种通知类型、事务的七种传播行为。现在这些依然会考但更多只是引子真正的重心转向了实际场景给你一个半成品 Spring Boot 项目让你说清楚自动配置是怎么触发的问你线上某个事务为什么没回滚让你根据代码定位失效原因让你解释三级缓存并且说明为什么二级缓存做不到给你一个微服务故障场景让你分析是哪个组件出了问题注册中心、配置中心、网关各自扮演什么角色。这种变化背后是招聘方对候选人的要求从“背文档的机器”变成了“能解决实际问题的人”。所以复习时每记住一个概念都要追问自己两句这个设计解决了什么问题如果不这样设计会踩什么坑把这两个问题想透面试场上大部分问题都能接得住。1.3 高频方向统计与优先级排序结合近两年的面试反馈和热搜趋势我按出现频率把 Spring 相关考点排了个优先级表格方便大家分配复习精力优先级考点方向代表性问题出现概率极高IoC 与 Bean 生命周期Bean 完整生命周期、注入方式选择几乎必考极高循环依赖与三级缓存三级缓存为什么是三级、哪些循环依赖无解高频高AOP 与动态代理JDK 动态代理 vs CGLIB、切面执行顺序高频高事务与传播行为事务失效场景、REQUIRED vs REQUIRES_NEW高频高Spring Boot 自动配置自动装配原理、自定义 starter高频中高Spring MVC 请求流程DispatcherServlet 工作流程、拦截器原理中频中高Spring Cloud 微服务服务注册发现、熔断限流、配置中心中频中Spring Security / OAuth过滤器链、OAuth 2.1 变化中频中Spring AIRAG、Agent、模型客户端抽象新兴方向增速很快这个表建议保存下来复习时按优先级投入时间。极高优先级的内容必须能吃透原理并能落地讲解中频的至少能说出核心概念和一个实际应用案例。不用追求每个冷门知识点都滚瓜烂熟但高频题一定要有“手拿把攥”的自信。2. IoC 和 Bean 生命周期——Spring 面试的地基考点2.1 控制反转为什么存在从 new 对象讲到容器管理Spring 面试的第一道题十有八九是控制反转和依赖注入。这不是题目简单而是面试官想先确认你有没有理解 Spring 存在的意义。“控制反转”这个词说起来抽象但用生活化的例子就好懂多了。以前你在单位食堂吃饭中午吃什么自己走到窗口选这叫“正向控制”后来改成订餐系统你把需求提交给系统系统根据你提交的信息把餐送过来——“吃什么”这个控制权从你手里交到了系统手里这就是“反转”。Spring 干的正是这件事对象的创建权以及对象之间依赖关系的管理权从程序员手里交到了 IoC 容器手里。所以当听到有人把控制反转用“把对象的创建交给容器管理”一句话讲完我一般会追问一句那好处是什么这句话基本决定了面试的走向。如果只说出“解耦”两个字其实不太够。一个高分回答应该包含三点一是对象生命周期集中管理创建、初始化、销毁都由容器负责代码里不再散落着不可控的 new 和配对混乱的 destroy二是依赖关系从硬编码变成了可配置、可替换测试时能注入 mock 对象三是配合 AOP 可以对容器里的所有 Bean 做统一增强比如事务、日志、监控这是直接用 new 创建对象很难做到的。2.2 Bean 生命周期面试回答说到哪一层才算过关Bean 生命周期是 Spring 面试中细节最多、最容易翻车的一道题。面试官一般不会让你背流程图而是让你从代码的视角描述一个 Bean 从“出生”到“死亡”的完整过程。我把标准流程整理成一个可以直接背下来的版本Spring 根据配置扫描到 BeanDefinition把它注册进 IoC 容器实例化前阶段执行 BeanDefinitionRegistryPostProcessor、BeanFactoryPostProcessor 这类容器级别的后处理器创建 Bean 实例——通过构造函数或工厂方法实例化对象本体属性填充——把依赖的 Bean、配置值注入进去依赖注入发生在这个阶段Aware 回调——实现 BeanNameAware、BeanFactoryAware、ApplicationContextAware 的 Bean 会收到对应回调初始化前置处理——BeanPostProcessor 的 postProcessBeforeInitialization 执行执行初始化——调用 InitializingBean.afterPropertiesSet 或自定义的 init-method初始化后置处理——BeanPostProcessor 的 postProcessAfterInitialization 执行AOP 代理创建的重要时机就在这里使用阶段——Bean 对象被业务代码正常调用销毁阶段——容器关闭时执行 DisposableBean.destroy 或自定义 destroy-method。很多人能一口气背完这十个阶段但真正拉开差距的是“每个阶段背后的代码时机”。比如第 8 步AOP 代理是在 BeanPostProcessor 的后置处理中生成的。也就是说代理对象是在原始对象完成初始化之后才被包装出来的原始对象和代理对象并不是同一个对象。这个点很多人会忽略一旦被追问“为什么绕过代理调用内部方法会导致事务失效”就可以顺理成章地从这里展开。我平时给团队新人讲的时候给过一个口诀先实例化再初始化最后代理。一句口诀串起来面试时顺着展开既记得牢又显得有体系。2.3 依赖注入方式对比面试官期待的实操判断依赖注入有三种常见写法字段注入Autowired 直接打在字段上、Setter 注入、构造器注入。面试官问“你平时用哪种”往往不是在要求站队而是想看你有没有形成自己的工程判断。先给结论构造器注入是 Spring 官方推荐、也是老手普遍认可的首选方式。原因在于它有一个天然优点——依赖在对象创建时就是完整且不可变的这符合“依赖不可变”的设计原则也规避了字段注入最容易出现的空指针问题。另外构造器注入对测试友好new 出来就能用不需要借助容器去“喂”属性。字段注入写起来最方便但问题不少类对容器存在隐式依赖脱离 Spring 容器做单元测试会变得困难依赖关系不透明读代码时无法一眼看清这个类到底依赖谁更隐蔽的是字段注入配合循环依赖时问题会更难排查。不过面试时如果只说“构造器注入好”也还是不太够。更好的回答是补一句“但构造器注入会让构造器参数变长当参数太多时应当考虑拆分类的职责而不是为了图省事改回字段注入”。这句话很加分因为说明你真的在项目里做过权衡而不是只会背结论。3. 循环依赖与三级缓存——Spring 面试题里的“硬核难度”3.1 一道经典连环问Spring 到底怎么解决循环依赖只要 Spring 面试题里出现“三级缓存”四个字这道题大概率就是全场难度高峰。先明确问题本身两个 Bean A 和 BA 的构造器需要 BB 的构造器需要 A这种构造器注入型的循环依赖Spring 解决不了——这是第一处容易翻车的点。Spring 能解决的是“Setter 注入或字段注入 单例 Bean”的循环依赖。整体过程可以这样理解A 开始创建后实例化出原始对象将它放入三级缓存接着 A 填充属性发现需要 B于是容器转去创建 BB 实例化、初始化在填充属性时发现又需要 A这时 B 从三级缓存里找到 A 的半成品引用拿到之后 B 顺利完成初始化并被放入一级缓存随后 A 继续完成自己的初始化最终也进入一级缓存。整个过程里三级缓存承担的就是那个“先给一个半成品临时用着”的角色。3.2 为什么一定要三级缓存而不是二级这是三级缓存面试题里最刁钻的追问。答案要落到AOP 代理上假设 A 被配置了 AOP需要生成代理对象。代理的创建时机是在 Bean 初始化完成之后、由 BeanPostProcessor 的后置处理来完成的。如果采用二级缓存设计A 在早期引用阶段根本拿不到代理对象——因为此时的 A 还没有完成初始化——那么 B 手里攥着的 A 永远是原始对象而不是代理对象AOP 对 A 的增强就彻底失效了。三级缓存设计的精妙之处在于三级缓存里保存的不是对象而是 ObjectFactory一个可以在“提前引用”这个时间点决策如何产出对象的工厂。当 B 请求 A 的早期引用时容器通过工厂判断如果 A 需要 AOP 增强就生成代理对象放进二级缓存不需要增强就直接返回原始对象。这样代理的产出时机被提前到了“半成品阶段”同时又不影响 Bean 自身的完整初始化流程。这样讲完面试官通常会跟你确认一个细节三级缓存里放的是“对象工厂”而不是“对象”。能主动把这个点说出来这道题基本就过关了。3.3 哪些循环依赖仍然救不了常见的救不了的循环依赖有四种面试大概率会抽其一场景为什么解决不了构造器注入的循环依赖对象还没实例化完三级缓存里根本没有半成品可用Prototype 作用域 Bean 的循环依赖原型 Bean 每次创建都是新对象容器不做缓存、不做提前引用Async 等方法级代理造成的循环依赖异步代理需要提前生成与早期引用机制产生冲突DependsOn 显式指定的循环依赖容器按配置顺序硬创建没有调剂余地面试中最常考的是第一种和第三种。第三种是经典翻车点明明只是加了一个 Async应用启动却直接报出循环依赖错误很多人百思不得其解。因为这时循环依赖是在代理机制的干扰下产生的单纯背“三级缓存能解决循环依赖”的人肯定答不上来。如果能进一步指出 Async 引发的循环依赖一般只能通过代码重构解除——比如拆分 Bean、改走事件机制——面试官会立刻觉得你是有真实项目经验的人。4. AOP 与事务——把框架机制落到业务故障排查上4.1 AOP 面试的四个必答层次AOP 面试题绝大多数人只能答出“面向切面编程把通用逻辑从业务代码里抽出来”这一句话。这太单薄了。面试官想听到的其实是四层递进的回答。第一层是基础概念切点Pointcut、通知Advice、切面Aspect、连接点JoinPoint。五种通知类型分别是前置、返回、异常、后置、环绕对应注解是 Before、AfterReturning、AfterThrowing、After、Around。第二层是底层实现原理AOP 基于动态代理实现。Spring 中的默认选择策略是——目标类实现接口时用 JDK 动态代理没有实现接口时用 CGLIB 字节码代理。JDK 代理本质是通过 InvocationHandler 在运行时创建接口的代理对象CGLIB 则是通过生成目标类子类的方式来创建代理。这里要注意版本细节Spring Boot 2.x 之后默认的 proxyTargetClass 已经变成 true很多情况下就算类实现了接口也走 CGLIB面试时能说出这个版本差异一定加分。第三层是执行顺序多个切面同时存在时用 Order 注解控制执行顺序。环切通知里方法执行顺序、目标方法、返回通知、后置通知之间谁先谁后能够准确描述出来才算真正理解。第四层是陷阱识别AOP 增强有效的前提是调用入口经过代理对象。同类内部方法自调用时不会经过代理因此 AOP 不生效——这和事务失效是同一个根源。面试官特别喜欢在这个点上做文章遇到时一定要直接点破“自调用绕过了代理”。4.2 Spring 事务失效的六种经典场景事务失效属于 Spring 面试里典型的“案例导向”题。面试官给你一段看起来没毛病的代码问“事务为什么没生效”让你定位原因。我整理六个高频失效场景每次面试几乎都会见到方法不是 publicSpring 的 Transactional 默认基于代理实现private 或 protected 方法不会进入代理逻辑事务直接失效同类内部自调用A 方法调用同类中的 B 方法B 虽然标了 Transactional但调用发生在代理外部事务失效异常被捕获方法内部 catch 住异常后没有重新抛出事务感知不到异常无法触发回滚异常类型不匹配默认只回滚 RuntimeException 和 Error如果抛的是受检异常如 IOException必须显式指定 rollbackFor否则事务照样提交——这是最隐蔽的一种失效数据库引擎不支持事务MySQL 的 MyISAM 引擎本身不支持事务无论代码配置多么正确数据一致性都无法保证Bean 没被容器管理类上没加 Service 或 Component或者组件扫描路径没覆盖到代理根本没有生成。第 4 种场景最值得深挖因为业务项目里“代码没问题、数据库也没问题、但数据就是不对”的事故绝大多数源于此。答题时最好带一句“我线上排查事务失效时第一步永远是看异常日志有没有被吞掉的痕迹而不是上来就翻代码”。这种排查思路会让面试官觉得你是有实战手感的人而不只是背了六条结论。4.3 事务传播行为七种行为与高频选择事务传播行为是 Spring 面试里“死记硬背”的黄金区域。七种传播行为分别是REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED。面试题一般只抽其中两个做对比REQUIRED 和 REQUIRES_NEW 是出场率最高的一组。简单总结REQUIRED 是当前有事务就加入没有就新建REQUIRES_NEW 是无论如何都新开一个独立事务当前事务会被挂起。典型的业务场景是日志记录、消息推送、外部接口调用这类不因主流程失败而需要回滚的动作通常用 REQUIRES_NEW正常业务关联操作默认用 REQUIRED保持同一个事务边界。还有一个容易混淆的点NESTED 和 REQUIRES_NEW 的区别。NESTED 是嵌套事务它和外围事务共享提交和回滚的整体框架部分回滚通过 savepoint 实现REQUIRES_NEW 则是彻底的独立事务提交和回滚互不影响。能说出“NESTED 的回滚基于 savepoint 实现”这句话面试官通常就会点头了。5. Spring Boot 与 MVC 面试题——从自动配置到请求全链路5.1 自动配置原理回答框架与关键组件Spring Boot 在面试中的地位近些年已经超过了 Spring 本体几乎每一轮技术面都会涉及。其中最强考点是自动配置原理。我推荐一个回答框架Spring Boot 项目启动时SpringBootApplication 注解实际上组合了 SpringBootConfiguration、EnableAutoConfiguration、ComponentScan 三个注解。其中 EnableAutoConfiguration 会通过 SpringFactoriesLoader 加载 META-INF/spring/.../AutoConfiguration.imports 文件里声明的自动配置类。每个自动配置类上通常有 ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty 等条件注解只有条件全部满足时对应的 Bean 才会被真正装配。能说出“条件注解”是这道题的第一道坎。第二道坎是“自动配置生效的前提为什么通常是类路径存在对应类”——举例来说引入 spring-boot-starter-web 后类路径里出现了 DispatcherServletWebMvcAutoConfiguration 中的条件才成立。正是这个机制让 Spring Boot 实现了“依赖即配置”无需显式写 XML。第三道坎是自定义 starter。如果面试官追问“怎么给自己的组件写 starter”一句话版流程是创建 autoconfigure 模块写 Configuration 配置类把配置类路径写进 AutoConfiguration.imports 文件再创建一个 starter 模块只放依赖用条件注解让配置可开关即可。5.2 Spring MVC 请求全链路从 DispatcherServlet 到视图渲染Spring MVC 是必考内容核心就是 DispatcherServlet 的工作流程。我建议用“一个请求进来之后发生了什么”来组织回答客户端发起请求首先到达 DispatcherServletDispatcherServlet 通过 HandlerMapping 找到处理该请求的 Controller 方法通过 HandlerAdapter 调用 Controller 方法这里会经过拦截器链Controller 方法执行后返回 ModelAndView 或直接返回数据如 ResponseBody如果是视图渲染场景ViewResolver 解析视图并渲染最终把响应返回客户端。面试官常追问的是拦截器和过滤器的区别。要点是Filter 是 Servlet 容器层面的在 DispatcherServlet 之前执行拦截器是 Spring MVC 层面的在 HandlerMapping 之后执行。另一个常见追问是“Controller 和 RestController 的区别”回答到“RestController 组合了 Controller 和 ResponseBody”才算及格。5.3 常见扩展点与配置关键字问答这部分是 Spring Boot 面试中的“实用型”考区。最近热搜里的 web socket yml 配置、spring boot日志、caffeine 都在这一块。WebSocket 集成Spring Boot 集成 WebSocket 一般三步。加依赖实现 WebSocketHandler配置类里注册 Handler 并指定端点路径。yml 里配置的通常是 STOMP 端点、消息代理前缀、跨域等。面试题常问“WebSocket 和 HTTP 的区别”答到“HTTP 是无状态请求响应模型WebSocket 是长连接双向通信模型”即可。日志配置Spring Boot 默认使用 Logbacklogback-spring.xml 优于 logback.xml原因在于前者能使用 springProfile 标签按环境激活不同的日志配置。yml 中的 logging.level 可以按包设置级别这是最常考的配置项之一。Bean 注入控制想控制 Bean 的创建顺序可以用 DependsOn也可以用配置类里 Bean 方法的调用链来显式表达依赖关系。需要人工控制顺序的场景不多但能说出来说明你踩过坑。Caffeine 缓存Caffeine 是比 Guava 性能更好的本地缓存集成方式是 spring.cache.typecaffeine再定义 CaffeineCacheManager。如果被问到淘汰策略能说出 Caffeine 默认基于 W-TinyLFU 策略就是加分细节。这些知识点看着零碎其实都是“用过才答得出细节”的题。面试官问它们的目的不是考记忆而是筛掉那些只看文档不跑项目的人。所以我每次都会建议每复习一个配置特性就手写一个小例子跑一遍低成本高回报。5.4 手写一个简化版 Spring——面试加分项“手写 Spring”这几年热度很高因为它确实能逼着人理解 IoC 和 AOP 的核心原理。我见过不少候选人在“如果让你实现一个简化版 Spring你怎么设计”这个问题前懵掉其实面试官只是想看你的抽象能力。一个最小可用的简化版 Spring拆成三步走IoC 部分自定义一个 ApplicationContext构造器里扫描包路径下带 Component 的类通过反射实例化所有单例 Bean再遍历 Bean 的字段把加了 Autowired 的字段通过反射设置进去AOP 部分在 Bean 创建后检查类方法是否有自定义注解比如 Transactional如果有就用 JDK 动态代理或者 CGLIB 生成代理对象在方法调用前后插入增强逻辑生命周期部分给 Bean 提供 afterPropertiesSet 模板方法在反射实例化完成后、属性填充完成后调用。这个练习坚持做完你会对 Spring 的“为什么这样设计”产生非常直观的感受。面试时提到“我周末自己写过简化版 Spring在这个过程中我深刻体会到 BeanPostProcessor 的设计价值”面试官对你的印象分会明显好于只会背源码的人。6. Spring Cloud 与微服务——压轴级面试考区6.1 微服务面试题的核心逻辑链路思维微服务面试和 Spring 核心面试最大的不同在于它考的是整个调用链路的串联能力而不是单个组件的 API 细节。面试官会给你一个“请求从网关进来经过服务 A 调用服务 B再到数据库返回结果”的场景然后让你说清每个环节用了哪些组件、每个组件的职责是什么、如果某处故障怎么排查。答题的正确姿势是沿着链路讲注册中心Nacos 或 Eureka负责服务发现 → 网关Spring Cloud Gateway负责路由和鉴权 → OpenFeign 负责服务间调用 → Sentinel 负责流量控制和熔断降级 → Nacos Config 负责配置管理 → Micrometer/Sleuth 负责链路追踪。把这条链路搭好之后追问的细节题基本会聚焦在两三个点上服务注册与发现的原理、熔断降级的流程、配置中心的热更新机制。把这三个点吃透微服务这关大概率能过。6.2 Spring Cloud Alibaba 套件面试高频问法Spring Cloud Alibaba 是近些年的热搜常客因为它的组件在中小企业的微服务落地中太常用了。高频考点有三个Nacos 与 Eureka 的区别Nacos 除了服务注册还支持配置中心、支持临时和持久化实例、支持服务端主动推送配置变更Eureka 只做注册发现且 Eureka 2.0 已经停止开源演进。Sentinel 与 Hystrix 的区别Hystrix 已经进入维护模式Sentinel 胜在轻量、有可视化管理控制台、流控规则更丰富。面试问“熔断和限流有什么区别”时核心答法是——限流是预防熔断是恢复限流控住入口流量熔断保护下游不被拖垮。Seata 分布式事务模式选择AT 模式侵入性最小但依赖全局锁和回滚日志TCC 模式性能好但需要业务方实现 Confirm 和 CancelSaga 适合长事务和最终一致性场景。还有一个精妙的经典问题“如果注册中心不可用服务间调用还能正常进行吗”答案里一定要提到客户端本地缓存——客户端会在内存中缓存服务实例列表注册中心挂掉后短期内服务间调用可以继续只是无法感知新上线的实例。能答出“本地缓存”四个字这道题就过关了。6.3 把 Python、AI 应用融入微服务体系——新热点热词里有“python应用融入spring cloud alibaba微服务体系”这其实是微服务面试题的一个新方向。面试官不是在问 Spring Cloud 能不能调 Python 服务而是想考察你有没有跨语言的服务治理思维。正确思路分三块一是用 OpenFeign 或 HTTP 调用对接 Python 服务保证接口协议基于 REST/JSON 就能互通二是让 Python 服务注册进 Nacos在注册中心里拥有自己的身份让服务发现机制可以统一调度三是使用 Sentinel 为所有服务配置统一的流量防护规则跨语言也能实现熔断限流。需要注意的是Python 服务需要自己实现健康检查接口和故障上报逻辑Spring Cloud 生态才能和它正常协作。7. Spring Security 与 OAuth 2.1——安全方向的核心考点7.1 Spring Security 核心过滤器链与认证授权流程Spring Security 的面试题核心只有一个词过滤器链。Spring Security 本质上就是一个过滤器链请求进来先经过 SecurityFilterChain 的层层过滤认证通过后才进入业务的 Controller 层。面试常问的点有两个。第一认证流程的核心组件AuthenticationFilter拦截请求并封装认证凭据、AuthenticationManager认证管理器决定认证逻辑、AuthenticationProvider具体认证逻辑比如从数据库查用户校验密码、SecurityContext认证成功后存放用户身份信息。第二Spring Boot 3 时代的迁移变化Spring Security 6 中 WebSecurityConfigurerAdapter 被彻底移除需要改为基于 SecurityFilterChain Bean 的方式配置oauth2Login、oauth2ResourceServer 的配置也需要写在 SecurityFilterChain 里。跑过迁移的人被问到会明显有底气因为这是实际踩坑换来的经验。7.2 OAuth 2.1从 2.0 到 2.1 的变化OAuth 2.1 的热度上升是因为大量公司开始处理跨系统授权问题。几个核心变化需要记住PKCEProof Key for Code Exchange从建议变成默认要求尤其公开客户端必须支持Implicit 授权模式从规范中移除授权码模式成为主推流程密码模式Resource Owner Password Credentials从规范移除密码登录场景改为走扩展实现刷新令牌规则更严格必须绑定客户端且要有明确的过期策略。面试里答 OAuth 的好路径是先用一个真实业务场景比如“第三方网站用微信扫码登录”或“公司内部系统的单点登录”把授权码模式的流程串一遍再点出 2.1 相对 2.0 的关键变化。能把抽象规范和真实案例结合安全方向这道题基本稳了。8. Spring AI——面试题里的新变量8.1 Spring AI 在面什么从接口抽象到应用框架Spring AI 是近两年 Spring 社区最火的新方向。这个关键词在热搜里反复出现意味着越来越多面试官开始聊它但考的大多不是源码而是大模型应用落地时的架构意识。Spring AI 本身是一个为 AI 应用提供基础能力的框架核心载体是统一的模型客户端和 ChatClient 接口。它要解决的问题很实际不同厂商的大模型 API 格式各不相同如果业务代码直接封装各家 API切换模型厂商的成本极高。Spring AI 通过统一接口把模型调用封装起来上层业务代码不关心底层是 OpenAI 还是通义千问、文心一言。8.2 高频 Spring AI 面试题RAG、Agent、NL2SQLRAG检索增强生成是 Spring AI 面试的基础概念。核心思路是先对知识文档做向量化处理存入向量数据库用户提问时先从向量库检索相关片段再把片段连同问题一起提交给大模型让模型基于检索内容来回答。这样模型不需要重新训练也能掌握领域知识同时能显著减少幻觉。Spring AI 提供了向量存储的抽象接口接入 Redis 或 Milvus 都很方便。Agent 和 NL2SQL属于进阶题。Agent 的核心考点是“工具调用”——让模型在回答过程中自主决定是否调用外部工具。比如用户问“帮我查一下本月的销售数据并按类别汇总”Agent 模型会先调用 SQL 查询工具拿到结果后再生成回答。NL2SQL 更务实如何把自然语言转成 SQL 并安全执行Spring AI 在 Spring Cloud Alibaba 的 AI 套件里已经有专门的实现方向。如果被问到 Spring AI 落地案例比较稳妥的回答是“我在做内部知识库问答时用 Spring AI 的 RAG 能力接入了文档系统用户提问时先从向量库检索相关片段再连同问题一起提交给模型生成答案效率比原来纯搜索引擎的模式明显提升。”这种真实案例式回答比背几个 API 名有说服力得多。9. 高频错误、答题技巧与复习路径——面试现场的实战锦囊9.1 高频错误与答题雷区我在模拟面试和带新人的过程中总结了不少高频错误专门列出来提醒只讲概念不举业务场景。任何一道 Spring 面试题回答的后半段都应该跟一个“我在项目里遇到……当时……后来……”的句子没有场景的答案就是空壳。把 Spring 和 Spring Boot 混为一谈。这是入门级考点但每年都有人翻车。Spring Boot 是建立在 Spring 之上的快速开发框架它没有取代 Spring而是让 Spring 的配置和使用更简单。对版本不敏感。Spring Boot 2.x 与 3.x、Spring Security 5 与 6、OAuth 2.0 与 2.1差异都很明显。答题时最好带一句“这是基于 Spring Boot 3.x 的配置”版本意识会给你加分。口胡源码。如果要说源码就必须说对关键类名比如 DefaultListableBeanFactory、SingletonBeanRegistry。记不清就宁可不说也别随口编。9.2 面试答题的结构化技巧——四段法技术面跟行为面一样可以使用结构化表达。我在模拟面试中一直推荐“是什么 - 原理 - 场景 - 坑”四段法第一句给结论直接说出术语和核心机制第二句讲原理用一两句话讲清机制背后的设计逻辑第三句举场景结合自己做过的项目说明这个机制在什么场景下解决了什么问题第四句谈坑把实际踩过的坑或需要警惕的边界条件说出来。比如被问到“为什么要用三级缓存”标准四段法是结论三级缓存是 Spring 处理单例 Bean 循环依赖的机制原理一级缓存放完整 Bean二级缓存放早期引用三级缓存放对象工厂三级缓存的存在让 AOP 代理能在提前引用阶段被正确处理场景我在项目里遇到两个 Service 互相调用靠这个机制得以解决坑但如果循环依赖发生在构造器注入或 Async 场景三级缓存救不了只能重构。这套四段法练熟了遇到任何 Spring 题都不太容易出现“哑火”。9.3 复习路径与高频题回顾清单最后给一份可执行的复习路径参考。我建议按这个顺序准备花三天通读 Spring 核心概念与源码关键类IoC 容器、Bean 生命周期、AOP 代理、事务花两天跑一个 Spring Boot 项目手写一个自定义 starter验证自动配置原理用一天整理项目里用过的循环依赖、事务、AOP 场景写成案例卡花半天过一遍 Spring Cloud 链路注册中心、网关、Feign、Sentinel、配置中心各写一句话职责花半天熟悉 Spring Security 6 与 Spring AI 的入门概念各准备一个回答模板。复习完可以用九宫格自查一遍IoC、Bean 生命周期、循环依赖、AOP、事务、自动配置、MVC 流程、微服务链路、安全与 AI。九个方向每个都能说清楚“是什么、原理、场景、坑”Spring 面试题这块基本就做到心里有底了。我个人在多次被面试和面试别人的过程中最大的体会是Spring 考试的内容最终考的并不是背诵量而是你究竟把多少知识变成了自己的判断。那些能在回答里自然带出项目实践、故障现场和版本细节的人哪怕偶尔漏掉一两个纯记忆型知识点面试官通常也会给高分。所以复习时尽量少一点“背答案”的焦虑多一点“把原理讲成故事”的心态——这大概是 Spring 面试题从准备到通关之间最关键的一步。 Spring面试真题全解析：从Bean生命周期到三级缓存与微服务实战
Spring 面试题这东西圈里一直有个说法考的不是你会不会背而是看你到底用没用过。我在一线做后端开发这些年面试别人和被别人面加在一起上百场最深的感觉是——Spring 的知识点从来不是孤立存在的面试官问的问题背后永远跟着一个“为什么”和一个“你项目里踩过什么坑”。最近的搜索热度也能看出来除了最基础的 spring 概念大家搜得最多的是 spring boot、spring三级缓存、spring ai、spring cloud alibaba、spring security、bean生命周期、手写 spring——这些恰恰是这些年面试真题里最常出现的考点。这篇内容我打算按这套热度地图走一遍把 Spring 面试中的高频考点、每个考点背后的原理、面试官真正想听到的回答路径以及我实际复习和带人过程中总结的经验都展开讲透。无论你是刚准备校招的应届生还是想跳槽的三年经验后端这篇都值得当作一份复习提纲来用。1. Spring 面试题的考点地图——先搞清楚面试官在考什么1.1 考点不是散点而是一条连贯的知识链很多人准备 Spring 面试是照着题库一条条背的什么是 IoC什么是 AOPBean 生命周期是什么事务传播行为有哪几种背完觉得自己都会一到面试现场被追问一句“那你项目里哪里用到了反射”就直接卡壳。问题出在把 Spring 学成了一个个孤立的点而面试官心中其实有一条清晰的知识链容器如何管理对象 → 对象之间如何协作 → 对象在特殊场景下如何处理代理、事务、安全→ 如何快速开发和部署Spring Boot→ 如何支撑大规模分布式系统Spring Cloud。这条链上的每个环节都对应一类核心考题而面试官追问的永远是“链与链之间的衔接点”。比如问你“什么是 IoC 容器”下一句往往就是“Bean 是怎么被创建出来的”“创建过程中如果出现循环依赖怎么办”“这个 Bean 的代理对象是谁创建的”“代理对象和普通对象有什么区别”。这些问题一环扣一环任何一环含糊都会露馅。所以我一直建议准备 Spring 面试以 Bean 从定义到销毁的完整生命周期为主线来组织知识体系比按题目分类背题有效得多。1.2 近年面试题的变化从“背定义”到“考实战”前些年的 Spring 面试题风格更偏概念背诵说出 IoC 的四种注入方式、AOP 的五种通知类型、事务的七种传播行为。现在这些依然会考但更多只是引子真正的重心转向了实际场景给你一个半成品 Spring Boot 项目让你说清楚自动配置是怎么触发的问你线上某个事务为什么没回滚让你根据代码定位失效原因让你解释三级缓存并且说明为什么二级缓存做不到给你一个微服务故障场景让你分析是哪个组件出了问题注册中心、配置中心、网关各自扮演什么角色。这种变化背后是招聘方对候选人的要求从“背文档的机器”变成了“能解决实际问题的人”。所以复习时每记住一个概念都要追问自己两句这个设计解决了什么问题如果不这样设计会踩什么坑把这两个问题想透面试场上大部分问题都能接得住。1.3 高频方向统计与优先级排序结合近两年的面试反馈和热搜趋势我按出现频率把 Spring 相关考点排了个优先级表格方便大家分配复习精力优先级考点方向代表性问题出现概率极高IoC 与 Bean 生命周期Bean 完整生命周期、注入方式选择几乎必考极高循环依赖与三级缓存三级缓存为什么是三级、哪些循环依赖无解高频高AOP 与动态代理JDK 动态代理 vs CGLIB、切面执行顺序高频高事务与传播行为事务失效场景、REQUIRED vs REQUIRES_NEW高频高Spring Boot 自动配置自动装配原理、自定义 starter高频中高Spring MVC 请求流程DispatcherServlet 工作流程、拦截器原理中频中高Spring Cloud 微服务服务注册发现、熔断限流、配置中心中频中Spring Security / OAuth过滤器链、OAuth 2.1 变化中频中Spring AIRAG、Agent、模型客户端抽象新兴方向增速很快这个表建议保存下来复习时按优先级投入时间。极高优先级的内容必须能吃透原理并能落地讲解中频的至少能说出核心概念和一个实际应用案例。不用追求每个冷门知识点都滚瓜烂熟但高频题一定要有“手拿把攥”的自信。2. IoC 和 Bean 生命周期——Spring 面试的地基考点2.1 控制反转为什么存在从 new 对象讲到容器管理Spring 面试的第一道题十有八九是控制反转和依赖注入。这不是题目简单而是面试官想先确认你有没有理解 Spring 存在的意义。“控制反转”这个词说起来抽象但用生活化的例子就好懂多了。以前你在单位食堂吃饭中午吃什么自己走到窗口选这叫“正向控制”后来改成订餐系统你把需求提交给系统系统根据你提交的信息把餐送过来——“吃什么”这个控制权从你手里交到了系统手里这就是“反转”。Spring 干的正是这件事对象的创建权以及对象之间依赖关系的管理权从程序员手里交到了 IoC 容器手里。所以当听到有人把控制反转用“把对象的创建交给容器管理”一句话讲完我一般会追问一句那好处是什么这句话基本决定了面试的走向。如果只说出“解耦”两个字其实不太够。一个高分回答应该包含三点一是对象生命周期集中管理创建、初始化、销毁都由容器负责代码里不再散落着不可控的 new 和配对混乱的 destroy二是依赖关系从硬编码变成了可配置、可替换测试时能注入 mock 对象三是配合 AOP 可以对容器里的所有 Bean 做统一增强比如事务、日志、监控这是直接用 new 创建对象很难做到的。2.2 Bean 生命周期面试回答说到哪一层才算过关Bean 生命周期是 Spring 面试中细节最多、最容易翻车的一道题。面试官一般不会让你背流程图而是让你从代码的视角描述一个 Bean 从“出生”到“死亡”的完整过程。我把标准流程整理成一个可以直接背下来的版本Spring 根据配置扫描到 BeanDefinition把它注册进 IoC 容器实例化前阶段执行 BeanDefinitionRegistryPostProcessor、BeanFactoryPostProcessor 这类容器级别的后处理器创建 Bean 实例——通过构造函数或工厂方法实例化对象本体属性填充——把依赖的 Bean、配置值注入进去依赖注入发生在这个阶段Aware 回调——实现 BeanNameAware、BeanFactoryAware、ApplicationContextAware 的 Bean 会收到对应回调初始化前置处理——BeanPostProcessor 的 postProcessBeforeInitialization 执行执行初始化——调用 InitializingBean.afterPropertiesSet 或自定义的 init-method初始化后置处理——BeanPostProcessor 的 postProcessAfterInitialization 执行AOP 代理创建的重要时机就在这里使用阶段——Bean 对象被业务代码正常调用销毁阶段——容器关闭时执行 DisposableBean.destroy 或自定义 destroy-method。很多人能一口气背完这十个阶段但真正拉开差距的是“每个阶段背后的代码时机”。比如第 8 步AOP 代理是在 BeanPostProcessor 的后置处理中生成的。也就是说代理对象是在原始对象完成初始化之后才被包装出来的原始对象和代理对象并不是同一个对象。这个点很多人会忽略一旦被追问“为什么绕过代理调用内部方法会导致事务失效”就可以顺理成章地从这里展开。我平时给团队新人讲的时候给过一个口诀先实例化再初始化最后代理。一句口诀串起来面试时顺着展开既记得牢又显得有体系。2.3 依赖注入方式对比面试官期待的实操判断依赖注入有三种常见写法字段注入Autowired 直接打在字段上、Setter 注入、构造器注入。面试官问“你平时用哪种”往往不是在要求站队而是想看你有没有形成自己的工程判断。先给结论构造器注入是 Spring 官方推荐、也是老手普遍认可的首选方式。原因在于它有一个天然优点——依赖在对象创建时就是完整且不可变的这符合“依赖不可变”的设计原则也规避了字段注入最容易出现的空指针问题。另外构造器注入对测试友好new 出来就能用不需要借助容器去“喂”属性。字段注入写起来最方便但问题不少类对容器存在隐式依赖脱离 Spring 容器做单元测试会变得困难依赖关系不透明读代码时无法一眼看清这个类到底依赖谁更隐蔽的是字段注入配合循环依赖时问题会更难排查。不过面试时如果只说“构造器注入好”也还是不太够。更好的回答是补一句“但构造器注入会让构造器参数变长当参数太多时应当考虑拆分类的职责而不是为了图省事改回字段注入”。这句话很加分因为说明你真的在项目里做过权衡而不是只会背结论。3. 循环依赖与三级缓存——Spring 面试题里的“硬核难度”3.1 一道经典连环问Spring 到底怎么解决循环依赖只要 Spring 面试题里出现“三级缓存”四个字这道题大概率就是全场难度高峰。先明确问题本身两个 Bean A 和 BA 的构造器需要 BB 的构造器需要 A这种构造器注入型的循环依赖Spring 解决不了——这是第一处容易翻车的点。Spring 能解决的是“Setter 注入或字段注入 单例 Bean”的循环依赖。整体过程可以这样理解A 开始创建后实例化出原始对象将它放入三级缓存接着 A 填充属性发现需要 B于是容器转去创建 BB 实例化、初始化在填充属性时发现又需要 A这时 B 从三级缓存里找到 A 的半成品引用拿到之后 B 顺利完成初始化并被放入一级缓存随后 A 继续完成自己的初始化最终也进入一级缓存。整个过程里三级缓存承担的就是那个“先给一个半成品临时用着”的角色。3.2 为什么一定要三级缓存而不是二级这是三级缓存面试题里最刁钻的追问。答案要落到AOP 代理上假设 A 被配置了 AOP需要生成代理对象。代理的创建时机是在 Bean 初始化完成之后、由 BeanPostProcessor 的后置处理来完成的。如果采用二级缓存设计A 在早期引用阶段根本拿不到代理对象——因为此时的 A 还没有完成初始化——那么 B 手里攥着的 A 永远是原始对象而不是代理对象AOP 对 A 的增强就彻底失效了。三级缓存设计的精妙之处在于三级缓存里保存的不是对象而是 ObjectFactory一个可以在“提前引用”这个时间点决策如何产出对象的工厂。当 B 请求 A 的早期引用时容器通过工厂判断如果 A 需要 AOP 增强就生成代理对象放进二级缓存不需要增强就直接返回原始对象。这样代理的产出时机被提前到了“半成品阶段”同时又不影响 Bean 自身的完整初始化流程。这样讲完面试官通常会跟你确认一个细节三级缓存里放的是“对象工厂”而不是“对象”。能主动把这个点说出来这道题基本就过关了。3.3 哪些循环依赖仍然救不了常见的救不了的循环依赖有四种面试大概率会抽其一场景为什么解决不了构造器注入的循环依赖对象还没实例化完三级缓存里根本没有半成品可用Prototype 作用域 Bean 的循环依赖原型 Bean 每次创建都是新对象容器不做缓存、不做提前引用Async 等方法级代理造成的循环依赖异步代理需要提前生成与早期引用机制产生冲突DependsOn 显式指定的循环依赖容器按配置顺序硬创建没有调剂余地面试中最常考的是第一种和第三种。第三种是经典翻车点明明只是加了一个 Async应用启动却直接报出循环依赖错误很多人百思不得其解。因为这时循环依赖是在代理机制的干扰下产生的单纯背“三级缓存能解决循环依赖”的人肯定答不上来。如果能进一步指出 Async 引发的循环依赖一般只能通过代码重构解除——比如拆分 Bean、改走事件机制——面试官会立刻觉得你是有真实项目经验的人。4. AOP 与事务——把框架机制落到业务故障排查上4.1 AOP 面试的四个必答层次AOP 面试题绝大多数人只能答出“面向切面编程把通用逻辑从业务代码里抽出来”这一句话。这太单薄了。面试官想听到的其实是四层递进的回答。第一层是基础概念切点Pointcut、通知Advice、切面Aspect、连接点JoinPoint。五种通知类型分别是前置、返回、异常、后置、环绕对应注解是 Before、AfterReturning、AfterThrowing、After、Around。第二层是底层实现原理AOP 基于动态代理实现。Spring 中的默认选择策略是——目标类实现接口时用 JDK 动态代理没有实现接口时用 CGLIB 字节码代理。JDK 代理本质是通过 InvocationHandler 在运行时创建接口的代理对象CGLIB 则是通过生成目标类子类的方式来创建代理。这里要注意版本细节Spring Boot 2.x 之后默认的 proxyTargetClass 已经变成 true很多情况下就算类实现了接口也走 CGLIB面试时能说出这个版本差异一定加分。第三层是执行顺序多个切面同时存在时用 Order 注解控制执行顺序。环切通知里方法执行顺序、目标方法、返回通知、后置通知之间谁先谁后能够准确描述出来才算真正理解。第四层是陷阱识别AOP 增强有效的前提是调用入口经过代理对象。同类内部方法自调用时不会经过代理因此 AOP 不生效——这和事务失效是同一个根源。面试官特别喜欢在这个点上做文章遇到时一定要直接点破“自调用绕过了代理”。4.2 Spring 事务失效的六种经典场景事务失效属于 Spring 面试里典型的“案例导向”题。面试官给你一段看起来没毛病的代码问“事务为什么没生效”让你定位原因。我整理六个高频失效场景每次面试几乎都会见到方法不是 publicSpring 的 Transactional 默认基于代理实现private 或 protected 方法不会进入代理逻辑事务直接失效同类内部自调用A 方法调用同类中的 B 方法B 虽然标了 Transactional但调用发生在代理外部事务失效异常被捕获方法内部 catch 住异常后没有重新抛出事务感知不到异常无法触发回滚异常类型不匹配默认只回滚 RuntimeException 和 Error如果抛的是受检异常如 IOException必须显式指定 rollbackFor否则事务照样提交——这是最隐蔽的一种失效数据库引擎不支持事务MySQL 的 MyISAM 引擎本身不支持事务无论代码配置多么正确数据一致性都无法保证Bean 没被容器管理类上没加 Service 或 Component或者组件扫描路径没覆盖到代理根本没有生成。第 4 种场景最值得深挖因为业务项目里“代码没问题、数据库也没问题、但数据就是不对”的事故绝大多数源于此。答题时最好带一句“我线上排查事务失效时第一步永远是看异常日志有没有被吞掉的痕迹而不是上来就翻代码”。这种排查思路会让面试官觉得你是有实战手感的人而不只是背了六条结论。4.3 事务传播行为七种行为与高频选择事务传播行为是 Spring 面试里“死记硬背”的黄金区域。七种传播行为分别是REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED。面试题一般只抽其中两个做对比REQUIRED 和 REQUIRES_NEW 是出场率最高的一组。简单总结REQUIRED 是当前有事务就加入没有就新建REQUIRES_NEW 是无论如何都新开一个独立事务当前事务会被挂起。典型的业务场景是日志记录、消息推送、外部接口调用这类不因主流程失败而需要回滚的动作通常用 REQUIRES_NEW正常业务关联操作默认用 REQUIRED保持同一个事务边界。还有一个容易混淆的点NESTED 和 REQUIRES_NEW 的区别。NESTED 是嵌套事务它和外围事务共享提交和回滚的整体框架部分回滚通过 savepoint 实现REQUIRES_NEW 则是彻底的独立事务提交和回滚互不影响。能说出“NESTED 的回滚基于 savepoint 实现”这句话面试官通常就会点头了。5. Spring Boot 与 MVC 面试题——从自动配置到请求全链路5.1 自动配置原理回答框架与关键组件Spring Boot 在面试中的地位近些年已经超过了 Spring 本体几乎每一轮技术面都会涉及。其中最强考点是自动配置原理。我推荐一个回答框架Spring Boot 项目启动时SpringBootApplication 注解实际上组合了 SpringBootConfiguration、EnableAutoConfiguration、ComponentScan 三个注解。其中 EnableAutoConfiguration 会通过 SpringFactoriesLoader 加载 META-INF/spring/.../AutoConfiguration.imports 文件里声明的自动配置类。每个自动配置类上通常有 ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty 等条件注解只有条件全部满足时对应的 Bean 才会被真正装配。能说出“条件注解”是这道题的第一道坎。第二道坎是“自动配置生效的前提为什么通常是类路径存在对应类”——举例来说引入 spring-boot-starter-web 后类路径里出现了 DispatcherServletWebMvcAutoConfiguration 中的条件才成立。正是这个机制让 Spring Boot 实现了“依赖即配置”无需显式写 XML。第三道坎是自定义 starter。如果面试官追问“怎么给自己的组件写 starter”一句话版流程是创建 autoconfigure 模块写 Configuration 配置类把配置类路径写进 AutoConfiguration.imports 文件再创建一个 starter 模块只放依赖用条件注解让配置可开关即可。5.2 Spring MVC 请求全链路从 DispatcherServlet 到视图渲染Spring MVC 是必考内容核心就是 DispatcherServlet 的工作流程。我建议用“一个请求进来之后发生了什么”来组织回答客户端发起请求首先到达 DispatcherServletDispatcherServlet 通过 HandlerMapping 找到处理该请求的 Controller 方法通过 HandlerAdapter 调用 Controller 方法这里会经过拦截器链Controller 方法执行后返回 ModelAndView 或直接返回数据如 ResponseBody如果是视图渲染场景ViewResolver 解析视图并渲染最终把响应返回客户端。面试官常追问的是拦截器和过滤器的区别。要点是Filter 是 Servlet 容器层面的在 DispatcherServlet 之前执行拦截器是 Spring MVC 层面的在 HandlerMapping 之后执行。另一个常见追问是“Controller 和 RestController 的区别”回答到“RestController 组合了 Controller 和 ResponseBody”才算及格。5.3 常见扩展点与配置关键字问答这部分是 Spring Boot 面试中的“实用型”考区。最近热搜里的 web socket yml 配置、spring boot日志、caffeine 都在这一块。WebSocket 集成Spring Boot 集成 WebSocket 一般三步。加依赖实现 WebSocketHandler配置类里注册 Handler 并指定端点路径。yml 里配置的通常是 STOMP 端点、消息代理前缀、跨域等。面试题常问“WebSocket 和 HTTP 的区别”答到“HTTP 是无状态请求响应模型WebSocket 是长连接双向通信模型”即可。日志配置Spring Boot 默认使用 Logbacklogback-spring.xml 优于 logback.xml原因在于前者能使用 springProfile 标签按环境激活不同的日志配置。yml 中的 logging.level 可以按包设置级别这是最常考的配置项之一。Bean 注入控制想控制 Bean 的创建顺序可以用 DependsOn也可以用配置类里 Bean 方法的调用链来显式表达依赖关系。需要人工控制顺序的场景不多但能说出来说明你踩过坑。Caffeine 缓存Caffeine 是比 Guava 性能更好的本地缓存集成方式是 spring.cache.typecaffeine再定义 CaffeineCacheManager。如果被问到淘汰策略能说出 Caffeine 默认基于 W-TinyLFU 策略就是加分细节。这些知识点看着零碎其实都是“用过才答得出细节”的题。面试官问它们的目的不是考记忆而是筛掉那些只看文档不跑项目的人。所以我每次都会建议每复习一个配置特性就手写一个小例子跑一遍低成本高回报。5.4 手写一个简化版 Spring——面试加分项“手写 Spring”这几年热度很高因为它确实能逼着人理解 IoC 和 AOP 的核心原理。我见过不少候选人在“如果让你实现一个简化版 Spring你怎么设计”这个问题前懵掉其实面试官只是想看你的抽象能力。一个最小可用的简化版 Spring拆成三步走IoC 部分自定义一个 ApplicationContext构造器里扫描包路径下带 Component 的类通过反射实例化所有单例 Bean再遍历 Bean 的字段把加了 Autowired 的字段通过反射设置进去AOP 部分在 Bean 创建后检查类方法是否有自定义注解比如 Transactional如果有就用 JDK 动态代理或者 CGLIB 生成代理对象在方法调用前后插入增强逻辑生命周期部分给 Bean 提供 afterPropertiesSet 模板方法在反射实例化完成后、属性填充完成后调用。这个练习坚持做完你会对 Spring 的“为什么这样设计”产生非常直观的感受。面试时提到“我周末自己写过简化版 Spring在这个过程中我深刻体会到 BeanPostProcessor 的设计价值”面试官对你的印象分会明显好于只会背源码的人。6. Spring Cloud 与微服务——压轴级面试考区6.1 微服务面试题的核心逻辑链路思维微服务面试和 Spring 核心面试最大的不同在于它考的是整个调用链路的串联能力而不是单个组件的 API 细节。面试官会给你一个“请求从网关进来经过服务 A 调用服务 B再到数据库返回结果”的场景然后让你说清每个环节用了哪些组件、每个组件的职责是什么、如果某处故障怎么排查。答题的正确姿势是沿着链路讲注册中心Nacos 或 Eureka负责服务发现 → 网关Spring Cloud Gateway负责路由和鉴权 → OpenFeign 负责服务间调用 → Sentinel 负责流量控制和熔断降级 → Nacos Config 负责配置管理 → Micrometer/Sleuth 负责链路追踪。把这条链路搭好之后追问的细节题基本会聚焦在两三个点上服务注册与发现的原理、熔断降级的流程、配置中心的热更新机制。把这三个点吃透微服务这关大概率能过。6.2 Spring Cloud Alibaba 套件面试高频问法Spring Cloud Alibaba 是近些年的热搜常客因为它的组件在中小企业的微服务落地中太常用了。高频考点有三个Nacos 与 Eureka 的区别Nacos 除了服务注册还支持配置中心、支持临时和持久化实例、支持服务端主动推送配置变更Eureka 只做注册发现且 Eureka 2.0 已经停止开源演进。Sentinel 与 Hystrix 的区别Hystrix 已经进入维护模式Sentinel 胜在轻量、有可视化管理控制台、流控规则更丰富。面试问“熔断和限流有什么区别”时核心答法是——限流是预防熔断是恢复限流控住入口流量熔断保护下游不被拖垮。Seata 分布式事务模式选择AT 模式侵入性最小但依赖全局锁和回滚日志TCC 模式性能好但需要业务方实现 Confirm 和 CancelSaga 适合长事务和最终一致性场景。还有一个精妙的经典问题“如果注册中心不可用服务间调用还能正常进行吗”答案里一定要提到客户端本地缓存——客户端会在内存中缓存服务实例列表注册中心挂掉后短期内服务间调用可以继续只是无法感知新上线的实例。能答出“本地缓存”四个字这道题就过关了。6.3 把 Python、AI 应用融入微服务体系——新热点热词里有“python应用融入spring cloud alibaba微服务体系”这其实是微服务面试题的一个新方向。面试官不是在问 Spring Cloud 能不能调 Python 服务而是想考察你有没有跨语言的服务治理思维。正确思路分三块一是用 OpenFeign 或 HTTP 调用对接 Python 服务保证接口协议基于 REST/JSON 就能互通二是让 Python 服务注册进 Nacos在注册中心里拥有自己的身份让服务发现机制可以统一调度三是使用 Sentinel 为所有服务配置统一的流量防护规则跨语言也能实现熔断限流。需要注意的是Python 服务需要自己实现健康检查接口和故障上报逻辑Spring Cloud 生态才能和它正常协作。7. Spring Security 与 OAuth 2.1——安全方向的核心考点7.1 Spring Security 核心过滤器链与认证授权流程Spring Security 的面试题核心只有一个词过滤器链。Spring Security 本质上就是一个过滤器链请求进来先经过 SecurityFilterChain 的层层过滤认证通过后才进入业务的 Controller 层。面试常问的点有两个。第一认证流程的核心组件AuthenticationFilter拦截请求并封装认证凭据、AuthenticationManager认证管理器决定认证逻辑、AuthenticationProvider具体认证逻辑比如从数据库查用户校验密码、SecurityContext认证成功后存放用户身份信息。第二Spring Boot 3 时代的迁移变化Spring Security 6 中 WebSecurityConfigurerAdapter 被彻底移除需要改为基于 SecurityFilterChain Bean 的方式配置oauth2Login、oauth2ResourceServer 的配置也需要写在 SecurityFilterChain 里。跑过迁移的人被问到会明显有底气因为这是实际踩坑换来的经验。7.2 OAuth 2.1从 2.0 到 2.1 的变化OAuth 2.1 的热度上升是因为大量公司开始处理跨系统授权问题。几个核心变化需要记住PKCEProof Key for Code Exchange从建议变成默认要求尤其公开客户端必须支持Implicit 授权模式从规范中移除授权码模式成为主推流程密码模式Resource Owner Password Credentials从规范移除密码登录场景改为走扩展实现刷新令牌规则更严格必须绑定客户端且要有明确的过期策略。面试里答 OAuth 的好路径是先用一个真实业务场景比如“第三方网站用微信扫码登录”或“公司内部系统的单点登录”把授权码模式的流程串一遍再点出 2.1 相对 2.0 的关键变化。能把抽象规范和真实案例结合安全方向这道题基本稳了。8. Spring AI——面试题里的新变量8.1 Spring AI 在面什么从接口抽象到应用框架Spring AI 是近两年 Spring 社区最火的新方向。这个关键词在热搜里反复出现意味着越来越多面试官开始聊它但考的大多不是源码而是大模型应用落地时的架构意识。Spring AI 本身是一个为 AI 应用提供基础能力的框架核心载体是统一的模型客户端和 ChatClient 接口。它要解决的问题很实际不同厂商的大模型 API 格式各不相同如果业务代码直接封装各家 API切换模型厂商的成本极高。Spring AI 通过统一接口把模型调用封装起来上层业务代码不关心底层是 OpenAI 还是通义千问、文心一言。8.2 高频 Spring AI 面试题RAG、Agent、NL2SQLRAG检索增强生成是 Spring AI 面试的基础概念。核心思路是先对知识文档做向量化处理存入向量数据库用户提问时先从向量库检索相关片段再把片段连同问题一起提交给大模型让模型基于检索内容来回答。这样模型不需要重新训练也能掌握领域知识同时能显著减少幻觉。Spring AI 提供了向量存储的抽象接口接入 Redis 或 Milvus 都很方便。Agent 和 NL2SQL属于进阶题。Agent 的核心考点是“工具调用”——让模型在回答过程中自主决定是否调用外部工具。比如用户问“帮我查一下本月的销售数据并按类别汇总”Agent 模型会先调用 SQL 查询工具拿到结果后再生成回答。NL2SQL 更务实如何把自然语言转成 SQL 并安全执行Spring AI 在 Spring Cloud Alibaba 的 AI 套件里已经有专门的实现方向。如果被问到 Spring AI 落地案例比较稳妥的回答是“我在做内部知识库问答时用 Spring AI 的 RAG 能力接入了文档系统用户提问时先从向量库检索相关片段再连同问题一起提交给模型生成答案效率比原来纯搜索引擎的模式明显提升。”这种真实案例式回答比背几个 API 名有说服力得多。9. 高频错误、答题技巧与复习路径——面试现场的实战锦囊9.1 高频错误与答题雷区我在模拟面试和带新人的过程中总结了不少高频错误专门列出来提醒只讲概念不举业务场景。任何一道 Spring 面试题回答的后半段都应该跟一个“我在项目里遇到……当时……后来……”的句子没有场景的答案就是空壳。把 Spring 和 Spring Boot 混为一谈。这是入门级考点但每年都有人翻车。Spring Boot 是建立在 Spring 之上的快速开发框架它没有取代 Spring而是让 Spring 的配置和使用更简单。对版本不敏感。Spring Boot 2.x 与 3.x、Spring Security 5 与 6、OAuth 2.0 与 2.1差异都很明显。答题时最好带一句“这是基于 Spring Boot 3.x 的配置”版本意识会给你加分。口胡源码。如果要说源码就必须说对关键类名比如 DefaultListableBeanFactory、SingletonBeanRegistry。记不清就宁可不说也别随口编。9.2 面试答题的结构化技巧——四段法技术面跟行为面一样可以使用结构化表达。我在模拟面试中一直推荐“是什么 - 原理 - 场景 - 坑”四段法第一句给结论直接说出术语和核心机制第二句讲原理用一两句话讲清机制背后的设计逻辑第三句举场景结合自己做过的项目说明这个机制在什么场景下解决了什么问题第四句谈坑把实际踩过的坑或需要警惕的边界条件说出来。比如被问到“为什么要用三级缓存”标准四段法是结论三级缓存是 Spring 处理单例 Bean 循环依赖的机制原理一级缓存放完整 Bean二级缓存放早期引用三级缓存放对象工厂三级缓存的存在让 AOP 代理能在提前引用阶段被正确处理场景我在项目里遇到两个 Service 互相调用靠这个机制得以解决坑但如果循环依赖发生在构造器注入或 Async 场景三级缓存救不了只能重构。这套四段法练熟了遇到任何 Spring 题都不太容易出现“哑火”。9.3 复习路径与高频题回顾清单最后给一份可执行的复习路径参考。我建议按这个顺序准备花三天通读 Spring 核心概念与源码关键类IoC 容器、Bean 生命周期、AOP 代理、事务花两天跑一个 Spring Boot 项目手写一个自定义 starter验证自动配置原理用一天整理项目里用过的循环依赖、事务、AOP 场景写成案例卡花半天过一遍 Spring Cloud 链路注册中心、网关、Feign、Sentinel、配置中心各写一句话职责花半天熟悉 Spring Security 6 与 Spring AI 的入门概念各准备一个回答模板。复习完可以用九宫格自查一遍IoC、Bean 生命周期、循环依赖、AOP、事务、自动配置、MVC 流程、微服务链路、安全与 AI。九个方向每个都能说清楚“是什么、原理、场景、坑”Spring 面试题这块基本就做到心里有底了。我个人在多次被面试和面试别人的过程中最大的体会是Spring 考试的内容最终考的并不是背诵量而是你究竟把多少知识变成了自己的判断。那些能在回答里自然带出项目实践、故障现场和版本细节的人哪怕偶尔漏掉一两个纯记忆型知识点面试官通常也会给高分。所以复习时尽量少一点“背答案”的焦虑多一点“把原理讲成故事”的心态——这大概是 Spring 面试题从准备到通关之间最关键的一步。