Spring Boot 3.x面试全攻略：自动配置+事务+AOT，2026最新考点

无意间发现了一个巨牛巨牛巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01

一、开场：Spring Boot面试，你真的准备好了吗？

老铁们，咱说实话，现在Java后端面试有个怪现象——十个面试官九个问Spring Boot，但八个人都答不到点子上。你要是说"我会用注解启动应用"，那基本上等于你去相亲只说"我呼吸"，没啥竞争力。

Spring Boot都发展到3.5版本了，从2022年的3.0版本全面拥抱Jakarta EE 9，到2025年5月发布的3.5带来一堆王炸特性，面试考点早就不是"自动配置原理"六个字能概括的了。今天咱就把这玩意儿掰开了揉碎了讲，保你看完能和面试官掰扯半小时不落下风。

二、自动配置：从"黑魔法"到"透明厨房"

2.1 面试第一问：自动配置到底咋实现的？

很多小白一听到"自动配置"就头大，觉得这是Spring Boot的玄学。其实吧，这玩意儿就像你去海底捞吃饭——你落座（引入starter），服务员自动给你上毛巾、倒水、递菜单（自动配置Bean），你啥也不用说，但每样东西都出现在该出现的地方。

Spring Boot 3.x的自动配置核心就藏在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里。从3.0版本开始，官方彻底废弃了老版本的spring.factories方式，改成这种更清晰的imports文件。说白了，就是把"菜单"从后厨小黑板换成了电子点餐屏，效率更高。

// 这是Spring Boot 3.x自动配置的核心注解，标记在配置类上@AutoConfiguration@ConditionalOnClass(DataSource.class)// 类路径有DataSource才生效@EnableConfigurationProperties(DataSourceProperties.class)publicclassDataSourceAutoConfiguration{@Bean@ConditionalOnMissingBean// 容器里没有这个Bean我才创建publicDataSourcedataSource(DataSourcePropertiesproperties){// 创建数据源的魔法在这里returnDataSourceBuilder.create().url(properties.getUrl()).username(properties.getUsername()).build();}}

2.2 3.5版本新考点：TaskExecutor名称变更

有个坑得特别注意，Spring Boot 3.5搞了个"断舍离"——以前自动配置的TaskExecutor有两个名字：taskExecutor和applicationTaskExecutor。现在呢？只剩applicationTaskExecutor了。

这就好比你以前有两个手机号，一个是主号一个是副号，现在运营商把副号收了，你只留主号。如果你的代码里还在用@Qualifier("taskExecutor")注入线程池，升级到3.5直接报错。解决办法是加个别名兼容：

@ConfigurationpublicclassCompatibilityConfig{@BeanstaticBeanFactoryPostProcessortaskExecutorAlias(){returnbeanFactory->beanFactory.registerAlias("applicationTaskExecutor","taskExecutor");}}

2.3 条件注解全家桶：面试必背

面试官最爱问的"Condition系列"，你得门儿清：

• @ConditionalOnClass：类路径有这个类才生效（比如你有Redis依赖才配RedisTemplate）
• @ConditionalOnMissingBean：容器里缺这个Bean我才出手（避免重复造轮子）
• @ConditionalOnProperty：配置文件里开了某个开关才启用（比如spring.xxx.enabled=true）

这仨就像小区门禁：第一个看你是不是业主（有没有这个类），第二个看家里有没有人（有没有现成的Bean），第三个看你有没有带门禁卡（配置开关对没对）。

三、事务管理：从"一步错步步错"到"精准把控"

3.1 @Transactional到底管啥用？

面试高频题："Spring事务失效的场景有哪些？“这题要是答不上来，基本等于告诉面试官"我只会CRUD”。

Spring Boot 3.x里开启事务简单得很，启动类加个@EnableTransactionManagement，Service方法上贴@Transactional。但坑都在细节里：

@ServicepublicclassOrderService{@Transactional(rollbackFor=Exception.class)// 指定回滚条件publicvoidcreateOrder(OrderDTOdto){// 保存订单orderMapper.insert(dto);// 扣减库存 - 这里如果抛异常，上面插入会回滚stockService.deduct(dto.getSkuId(),dto.getCount());// 注意：如果这里调了同类里的另一个方法，事务会失效！// 因为Spring事务基于AOP代理，内部调用不走代理sendNotification();// 这样调用事务不生效！}@Transactional(propagation=Propagation.REQUIRES_NEW)publicvoidsendNotification(){// 需要独立事务的通知逻辑}}

3.2 传播机制与隔离级别：别只会背定义

面试官要问你"REQUIRED和REQUIRES_NEW啥区别"，别干巴巴背概念。打个比方：

• REQUIRED（默认）：就像搭顺风车，有车就坐，没车就新建一个。当前有事务就加入，没有就创建。
• REQUIRES_NEW：就像霸道总裁，不管外面有没有事务，我都要新建一个，且把原来的事务挂起。适合记录日志这种"无论如何都要成功"的操作。

隔离级别更简单理解：

• READ_UNCOMMITTED：你能看到别人还没提交的数据（脏读），就像偷看人家没写完的日记。
• READ_COMMITTED：只能看已提交的，Oracle默认就这级别。
• REPEATABLE_READ：MySQL默认，同一个事务里多次查结果一样，防住了不可重复读。
• SERIALIZABLE：串行化，效率最低但最安全，就像单车道，一辆车过了下一辆才能走。

3.3 分布式事务：Seata成主流方案

现在微服务架构下，单体事务不够用，面试官必问分布式事务。2025年的标准答案不再是"用XA协议"，而是Seata。

Seata的AT模式（自动补偿）最实用，原理简单：

1. 一阶段：业务数据操作和回滚日志记录在同一个本地事务里提交。
2. 二阶段：如果全局提交，异步删除回滚日志；如果回滚，用日志生成反向SQL补偿。

就像你网购下单，扣库存和创建订单是两个服务。Seata就像个"事务管家"，确保要么都成功，要么都回滚，不会出现"钱扣了订单没建"的尴尬。

无意间发现了一个巨牛巨牛巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门