企业官网建设流程全解析

Spring 面试题这东西，圈里一直有个说法：考的不是你会不会背，而是看你到底用没用过。我在一线做后端开发这些年，面试别人和被别人面加在一起上百场，最深的感觉是——Spring 的知识点从来不是孤立存在的，面试官问的问题背后永远跟着一个“为什么”和一个“你项目里踩过什么坑”。最近的搜索热度也能看出来，除了最基础的 spring 概念，大家搜得最多的是 spring boot、spring三级缓存、spring ai、spring cloud alibaba、spring security、bean生命周期、手写 spring——这些恰恰是这些年面试真题里最常出现的考点。

这篇内容我打算按这套热度地图走一遍，把 Spring 面试中的高频考点、每个考点背后的原理、面试官真正想听到的回答路径，以及我实际复习和带人过程中总结的经验，都展开讲透。无论你是刚准备校招的应届生，还是想跳槽的三年经验后端，这篇都值得当作一份复习提纲来用。

1. Spring 面试题的考点地图——先搞清楚面试官在考什么

1.1 考点不是散点，而是一条连贯的知识链

很多人准备 Spring 面试是照着题库一条条背的：什么是 IoC？什么是 AOP？Bean 生命周期是什么？事务传播行为有哪几种？背完觉得自己都会，一到面试现场被追问一句“那你项目里哪里用到了反射？”就直接卡壳。问题出在把 Spring 学成了一个个孤立的点，而面试官心中其实有一条清晰的知识链：容器如何管理对象 → 对象之间如何协作 → 对象在特殊场景下如何处理（代理、事务、安全）→ 如何快速开发和部署（Spring Boot）→ 如何支撑大规模分布式系统（Spring Cloud）。

这条链上的每个环节都对应一类核心考题，而面试官追问的永远是“链与链之间的衔接点”。比如问你“什么是 IoC 容器”，下一句往往就是“Bean 是怎么被创建出来的”“创建过程中如果出现循环依赖怎么办”“这个 Bean 的代理对象是谁创建的”“代理对象和普通对象有什么区别”。这些问题一环扣一环，任何一环含糊都会露馅。所以我一直建议：准备 Spring 面试，以 Bean 从定义到销毁的完整生命周期为主线来组织知识体系，比按题目分类背题有效得多。

1.2 近年面试题的变化：从“背定义”到“考实战”

前些年的 Spring 面试题风格更偏概念背诵：说出 IoC 的四种注入方式、AOP 的五种通知类型、事务的七种传播行为。现在这些依然会考，但更多只是引子，真正的重心转向了实际场景：

• 给你一个半成品 Spring Boot 项目，让你说清楚自动配置是怎么触发的；
• 问你线上某个事务为什么没回滚，让你根据代码定位失效原因；
• 让你解释三级缓存，并且说明为什么二级缓存做不到；
• 给你一个微服务故障场景，让你分析是哪个组件出了问题，注册中心、配置中心、网关各自扮演什么角色。

这种变化背后，是招聘方对候选人的要求从“背文档的机器”变成了“能解决实际问题的人”。所以复习时每记住一个概念，都要追问自己两句：这个设计解决了什么问题？如果不这样设计会踩什么坑？把这两个问题想透，面试场上大部分问题都能接得住。

1.3 高频方向统计与优先级排序

结合近两年的面试反馈和热搜趋势，我按出现频率把 Spring 相关考点排了个优先级表格，方便大家分配复习精力：

这个表建议保存下来，复习时按优先级投入时间。极高优先级的内容必须能吃透原理并能落地讲解，中频的至少能说出核心概念和一个实际应用案例。不用追求每个冷门知识点都滚瓜烂熟，但高频题一定要有“手拿把攥”的自信。

2. IoC 和 Bean 生命周期——Spring 面试的地基考点

2.1 控制反转为什么存在：从 new 对象讲到容器管理

Spring 面试的第一道题，十有八九是控制反转和依赖注入。这不是题目简单，而是面试官想先确认你有没有理解 Spring 存在的意义。

“控制反转”这个词说起来抽象，但用生活化的例子就好懂多了。以前你在单位食堂吃饭，中午吃什么自己走到窗口选，这叫“正向控制”；后来改成订餐系统，你把需求提交给系统，系统根据你提交的信息把餐送过来——“吃什么”这个控制权从你手里交到了系统手里，这就是“反转”。Spring 干的正是这件事：对象的创建权，以及对象之间依赖关系的管理权，从程序员手里交到了 IoC 容器手里。

所以当听到有人把控制反转用“把对象的创建交给容器管理”一句话讲完，我一般会追问一句：那好处是什么？这句话基本决定了面试的走向。如果只说出“解耦”两个字，其实不太够。一个高分回答应该包含三点：一是对象生命周期集中管理，创建、初始化、销毁都由容器负责，代码里不再散落着不可控的 new 和配对混乱的 destroy；二是依赖关系从硬编码变成了可配置、可替换，测试时能注入 mock 对象；三是配合 AOP 可以对容器里的所有 Bean 做统一增强，比如事务、日志、监控，这是直接用 new 创建对象很难做到的。

2.2 Bean 生命周期：面试回答说到哪一层才算过关

Bean 生命周期是 Spring 面试中细节最多、最容易翻车的一道题。面试官一般不会让你背流程图，而是让你从代码的视角描述一个 Bean 从“出生”到“死亡”的完整过程。

我把标准流程整理成一个可以直接背下来的版本：

1. Spring 根据配置扫描到 BeanDefinition，把它注册进 IoC 容器；
2. 实例化前阶段，执行 BeanDefinitionRegistryPostProcessor、BeanFactoryPostProcessor 这类容器级别的后处理器；
3. 创建 Bean 实例——通过构造函数或工厂方法实例化对象本体；
4. 属性填充——把依赖的 Bean、配置值注入进去，依赖注入发生在这个阶段；
5. Aware 回调——实现 BeanNameAware、BeanFactoryAware、ApplicationContextAware 的 Bean 会收到对应回调；
6. 初始化前置处理——BeanPostProcessor 的 postProcessBeforeInitialization 执行；
7. 执行初始化——调用 InitializingBean.afterPropertiesSet 或自定义的 init-method；
8. 初始化后置处理——BeanPostProcessor 的 postProcessAfterInitialization 执行，AOP 代理创建的重要时机就在这里；
9. 使用阶段——Bean 对象被业务代码正常调用；
10. 销毁阶段——容器关闭时执行 DisposableBean.destroy 或自定义 destroy-method。

很多人能一口气背完这十个阶段，但真正拉开差距的是“每个阶段背后的代码时机”。比如第 8 步：AOP 代理是在 BeanPostProcessor 的后置处理中生成的。也就是说，代理对象是在原始对象完成初始化之后才被包装出来的，原始对象和代理对象并不是同一个对象。这个点很多人会忽略，一旦被追问“为什么绕过代理调用内部方法会导致事务失效”，就可以顺理成章地从这里展开。

我平时给团队新人讲的时候给过一个口诀：先实例化，再初始化，最后代理。一句口诀串起来，面试时顺着展开，既记得牢又显得有体系。

2.3 依赖注入方式对比：面试官期待的实操判断

依赖注入有三种常见写法：字段注入（@Autowired 直接打在字段上）、Setter 注入、构造器注入。面试官问“你平时用哪种”，往往不是在要求站队，而是想看你有没有形成自己的工程判断。

先给结论：构造器注入是 Spring 官方推荐、也是老手普遍认可的首选方式。原因在于它有一个天然优点——依赖在对象创建时就是完整且不可变的，这符合“依赖不可变”的设计原则，也规避了字段注入最容易出现的空指针问题。另外构造器注入对测试友好，new 出来就能用，不需要借助容器去“喂”属性。

字段注入写起来最方便，但问题不少：类对容器存在隐式依赖，脱离 Spring 容器做单元测试会变得困难；依赖关系不透明，读代码时无法一眼看清这个类到底依赖谁；更隐蔽的是，字段注入配合循环依赖时问题会更难排查。不过面试时如果只说“构造器注入好”，也还是不太够。更好的回答是补一句“但构造器注入会让构造器参数变长，当参数太多时应当考虑拆分类的职责，而不是为了图省事改回字段注入”。这句话很加分，因为说明你真的在项目里做过权衡，而不是只会背结论。

3. 循环依赖与三级缓存——Spring 面试题里的“硬核难度”

3.1 一道经典连环问：Spring 到底怎么解决循环依赖

只要 Spring 面试题里出现“三级缓存”四个字，这道题大概率就是全场难度高峰。先明确问题本身：两个 Bean A 和 B，A 的构造器需要 B，B 的构造器需要 A，这种构造器注入型的循环依赖，Spring 解决不了——这是第一处容易翻车的点。

Spring 能解决的是“Setter 注入或字段注入 + 单例 Bean”的循环依赖。整体过程可以这样理解：A 开始创建后，实例化出原始对象，将它放入三级缓存；接着 A 填充属性，发现需要 B，于是容器转去创建 B；B 实例化、初始化，在填充属性时发现又需要 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 哪些循环依赖仍然救不了

常见的救不了的循环依赖有四种，面试大概率会抽其一：

面试中最常考的是第一种和第三种。第三种是经典翻车点：明明只是加了一个 @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 面试里典型的“案例导向”题。面试官给你一段看起来没毛病的代码，问“事务为什么没生效”，让你定位原因。我整理六个高频失效场景，每次面试几乎都会见到：

1. 方法不是 public：Spring 的 @Transactional 默认基于代理实现，private 或 protected 方法不会进入代理逻辑，事务直接失效；
2. 同类内部自调用：A 方法调用同类中的 B 方法，B 虽然标了 @Transactional，但调用发生在代理外部，事务失效；
3. 异常被捕获：方法内部 catch 住异常后没有重新抛出，事务感知不到异常，无法触发回滚；
4. 异常类型不匹配：默认只回滚 RuntimeException 和 Error，如果抛的是受检异常（如 IOException），必须显式指定 rollbackFor，否则事务照样提交——这是最隐蔽的一种失效；
5. 数据库引擎不支持事务：MySQL 的 MyISAM 引擎本身不支持事务，无论代码配置多么正确，数据一致性都无法保证；
6. 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 后，类路径里出现了 DispatcherServlet，WebMvcAutoConfiguration 中的条件才成立。正是这个机制让 Spring Boot 实现了“依赖即配置”，无需显式写 XML。

第三道坎是自定义 starter。如果面试官追问“怎么给自己的组件写 starter”，一句话版流程是：创建 autoconfigure 模块，写 @Configuration 配置类，把配置类路径写进 AutoConfiguration.imports 文件；再创建一个 starter 模块只放依赖；用条件注解让配置可开关即可。

5.2 Spring MVC 请求全链路：从 DispatcherServlet 到视图渲染

Spring MVC 是必考内容，核心就是 DispatcherServlet 的工作流程。我建议用“一个请求进来之后发生了什么”来组织回答：

1. 客户端发起请求，首先到达 DispatcherServlet；
2. DispatcherServlet 通过 HandlerMapping 找到处理该请求的 Controller 方法；
3. 通过 HandlerAdapter 调用 Controller 方法，这里会经过拦截器链；
4. Controller 方法执行后返回 ModelAndView 或直接返回数据（如 @ResponseBody）；
5. 如果是视图渲染场景，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 默认使用 Logback，logback-spring.xml 优于 logback.xml，原因在于前者能使用 springProfile 标签按环境激活不同的日志配置。yml 中的 logging.level 可以按包设置级别，这是最常考的配置项之一。
• Bean 注入控制：想控制 Bean 的创建顺序，可以用 @DependsOn，也可以用配置类里 @Bean 方法的调用链来显式表达依赖关系。需要人工控制顺序的场景不多，但能说出来说明你踩过坑。
• Caffeine 缓存：Caffeine 是比 Guava 性能更好的本地缓存，集成方式是 spring.cache.type=caffeine，再定义 CaffeineCacheManager。如果被问到淘汰策略，能说出 Caffeine 默认基于 W-TinyLFU 策略就是加分细节。

这些知识点看着零碎，其实都是“用过才答得出细节”的题。面试官问它们的目的不是考记忆，而是筛掉那些只看文档不跑项目的人。所以我每次都会建议：每复习一个配置特性，就手写一个小例子跑一遍，低成本高回报。

5.4 手写一个简化版 Spring——面试加分项

“手写 Spring”这几年热度很高，因为它确实能逼着人理解 IoC 和 AOP 的核心原理。我见过不少候选人在“如果让你实现一个简化版 Spring，你怎么设计”这个问题前懵掉，其实面试官只是想看你的抽象能力。

一个最小可用的简化版 Spring，拆成三步走：

1. IoC 部分：自定义一个 ApplicationContext，构造器里扫描包路径下带 @Component 的类，通过反射实例化所有单例 Bean，再遍历 Bean 的字段，把加了 @Autowired 的字段通过反射设置进去；
2. AOP 部分：在 Bean 创建后，检查类方法是否有自定义注解（比如 @Transactional），如果有，就用 JDK 动态代理或者 CGLIB 生成代理对象，在方法调用前后插入增强逻辑；
3. 生命周期部分：给 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 和 Cancel；Saga 适合长事务和最终一致性场景。

还有一个精妙的经典问题：“如果注册中心不可用，服务间调用还能正常进行吗？”答案里一定要提到客户端本地缓存——客户端会在内存中缓存服务实例列表，注册中心挂掉后短期内服务间调用可以继续，只是无法感知新上线的实例。能答出“本地缓存”四个字，这道题就过关了。

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 的热度上升，是因为大量公司开始处理跨系统授权问题。几个核心变化需要记住：

• PKCE（Proof 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、NL2SQL

RAG（检索增强生成）是 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 复习路径与高频题回顾清单

最后给一份可执行的复习路径参考。我建议按这个顺序准备：

1. 花三天通读 Spring 核心概念与源码关键类：IoC 容器、Bean 生命周期、AOP 代理、事务；
2. 花两天跑一个 Spring Boot 项目，手写一个自定义 starter，验证自动配置原理；
3. 用一天整理项目里用过的循环依赖、事务、AOP 场景，写成案例卡；
4. 花半天过一遍 Spring Cloud 链路：注册中心、网关、Feign、Sentinel、配置中心各写一句话职责；
5. 花半天熟悉 Spring Security 6 与 Spring AI 的入门概念，各准备一个回答模板。

复习完可以用九宫格自查一遍：IoC、Bean 生命周期、循环依赖、AOP、事务、自动配置、MVC 流程、微服务链路、安全与 AI。九个方向每个都能说清楚“是什么、原理、场景、坑”，Spring 面试题这块基本就做到心里有底了。

我个人在多次被面试和面试别人的过程中，最大的体会是：Spring 考试的内容最终考的并不是背诵量，而是你究竟把多少知识变成了自己的判断。那些能在回答里自然带出项目实践、故障现场和版本细节的人，哪怕偶尔漏掉一两个纯记忆型知识点，面试官通常也会给高分。所以复习时尽量少一点“背答案”的焦虑，多一点“把原理讲成故事”的心态——这大概是 Spring 面试题从准备到通关之间，最关键的一步。