开头最近陆续帮几个朋友做面试复盘发现一个很有意思的现象很多人背了一大堆“Spring Boot 面试题”什么“自动配置原理”“启动流程”“Conditional 注解”被问到的时候都能说出几个名词但再往下追问一层就卡壳了。比如“spring.factories 里的自动配置是怎么被加载出来的”“内嵌 Tomcat 是在容器刷新的哪个阶段启动的”“Redis Stream 消费的时候消息不确认会怎么样”——这些问题光靠背题是答不出来的。我自己的经验是Spring Boot 面试题的核心不在“背结论”而在“还原过程”。你可以不知道每一行源码但至少要能把一条链路讲清楚自动配置是怎么从 jar 包里的配置文件走到容器里的、启动流程哪一步做了什么、条件装配为什么是自动配置的灵魂。这篇文章就是围绕这些核心链路整理的笔记结合了我实际看过源码、调过生产问题的一些体会顺带把 Redis Stream 消费、预约服务系统这类实际项目里会碰到的场景也拆一下。无论你是正在准备面试还是想把手里的 Spring Boot 项目做得更扎实这份笔记都应该能帮到你。1. 自动配置不是黑魔法把SpringBootApplication拆开看1.1 核心入口三个注解的协同关系面试官最爱问的第一句话通常是“Spring Boot 为什么能省掉那么多 XML 配置”答案要从SpringBootApplication说起。这个注解是一个复合注解本质上它把下面三件事打包了SpringBootConfiguration底层是Configuration告诉 Spring 这个类是一个配置类可以注册 Bean。EnableAutoConfiguration开启自动配置这是最关键的一个。ComponentScan默认扫描启动类所在包及其子包下的Component、Service、Repository、Controller。ComponentScan和EnableAutoConfiguration放在一起很多初学者会混淆两者的职责。简单说ComponentScan负责“扫你自己项目里的 Bean”EnableAutoConfiguration负责“加载依赖 jar 包里预先定义好的配置类”。两者是互补的各管一摊。面试的时候如果只答到这里只能算及格。真正拉开差距的是下一个问题EnableAutoConfiguration到底是怎么把所有自动配置类加载进来的EnableAutoConfiguration的内部实现是Import(AutoConfigurationImportSelector.class)。这个AutoConfigurationImportSelector实现了ImportSelector接口它的selectImports方法会返回一个类名数组这些类名就是所有需要加载的自动配置类。你可以把Import理解成一个“批量导入器”AutoConfigurationImportSelector负责告诉 Spring 应该导入谁。1.2 AutoConfiguration.imports从spring.factories到新机制的迁移这里有一个非常实际的知识点也是面试中区分“背过题”和“看过源码”的好问题自动配置类的清单到底放在哪里早期版本Spring Boot 2.7 之前自动配置类的路径是META-INF/spring.factories文件里面通过org.springframework.boot.autoconfigure.EnableAutoConfiguration作为 key后面跟着一长串xxxAutoConfiguration的全限定类名。Spring Boot 2.7 引入了新的加载机制把清单迁移到了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件每一行写一个自动配置类全名不再有 key-value 结构。Spring Boot 3.0 之后spring.factories这种加载方式就被彻底移除了。我在实际升级老项目时踩过这个坑把一个 Spring Boot 2.3 的项目直接往上升级自定义的 starter 里还在用spring.factories声明自动配置类结果升级后自动配置完全不生效因为新版本的SpringFactoriesLoader已经没有自动加载EnableAutoConfiguration这一项了。解决办法是把自定义 starter 里的清单改到AutoConfiguration.imports文件中同时保留spring.factories里的其他 key比如ApplicationContextInitializer、EnvironmentPostProcessor那些仍然走spring.factories。META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports com.example.CustomAutoConfiguration面试时如果能主动说到这个版本迁移细节尤其提到“spring.factories里其实还留着其他 key只是自动配置这一项搬家了”面试官通常会比较认可因为这证明你不是只看了博客而是动手升过级。1.3 条件装配自动配置的灵魂把一堆xxxAutoConfiguration全都加载进来不代表全部生效。Spring Boot 最聪明的地方在于每个自动配置类上都挂了一堆条件注解俗称“条件装配”。常见的有ConditionalOnClass/ConditionalOnMissingClass类路径上有没有某个类。比如DataSourceAutoConfiguration上通常有ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })如果项目里没引入数据库驱动和连接池这个自动配置类就不装配。ConditionalOnBean/ConditionalOnMissingBean容器里有没有某个 Bean。如果你自己定义了DataSourceSpring Boot 就不会再用它默认的DataSource。ConditionalOnProperty配合application.properties里的配置项判断。比如ConditionalOnProperty(prefix spring.redis, name enabled, havingValue true)。ConditionalOnWebApplication当前是不是 Web 应用。这个在区分 WebMvc 和 WebFlux 配置时很关键。理解了条件装配就不难想明白一个经典面试题为什么你在项目里自定义了一个ObjectMapper的BeanSpring Boot 不会因此报冲突因为JacksonAutoConfiguration里有一个ConditionalOnMissingBean一旦容器里已经存在ObjectMapper它默认的ObjectMapper就不再创建了。这一点在定位“我的配置为什么不生效”的时候特别有用。我见过不少同事排查问题查了半天发现自己写的RestTemplate配置没生效打开自动配置报告一看原因就是某个 starter 里的ConditionalOnMissingBean被容器里另一个同名 Bean 先占了。1.4 调试自动配置打开报告看真相如果你不想对着源码猜Spring Boot 提供了一个非常实用的调试开关在application.properties里加一行debugtrue启动的时候日志里会打印一份完整的CONDITIONS EVALUATION REPORT分正匹配Positive matches和负匹配Negative matches两张表。Positive matches 列出的是“当前环境下生效的自动配置类”以及触发它的条件。Negative matches 列出的是“被跳过的自动配置类”并明确告诉你因为哪个条件不满足。有一次我排查一个RedisTemplate的序列化问题就是靠这份报告确认了RedisAutoConfiguration是否真的生效。你会发现RedisAutoconfiguration的正匹配条件里写着ConditionalOnClass匹配成功但ConditionalOnMissingBean(name redisTemplate)没有匹配成功——说明容器里已经有一个叫redisTemplate的 Bean我再自定义一份当然无效。这个开关在生产环境不要随便开日志量太大。但本地开发调试、面试前复盘自动配置真的非常实用。2. 启动流程Spring Boot在run()里替你做了什么2.1 从new SpringApplication到run()启动前的关键准备Spring Boot 启动的核心就两个阶段new SpringApplication(primarySources)和run(args)。很多面试复习资料只讲 run 阶段忽略了构造方法里做的前置工作但恰恰是构造方法里的逻辑决定了后面怎么走。构造方法里最重要的三件事推断应用类型。通过WebApplicationType.deduceFromClasspath()判断当前是 SERVLET 应用有javax.servlet.Servlet和ConfigurableWebApplicationContext、REACTIVE 应用有ReactiveStreams和DispatcherHandler还是 NONE非 Web。加载 ApplicationContextInitializer 和 ApplicationListener。这两个都是从spring.factories里加载的。它们可以在容器刷新前对ConfigurableApplicationContext做定制比如往环境中加入自定义的属性源。推断主配置类。通过堆栈信息找到包含main方法的类也就是标注了SpringBootApplication的启动类。如果你在面试中被问到“Spring Boot 怎么知道谁是启动类”答案就是通过new RuntimeException().getStackTrace()推断出来的。这个点比较冷门但说出来会显得你对细节有感知。2.2 刷新容器不是全部afterRefresh之后还有多少事run()方法的主链路可以概括为下面几步StopWatch stopWatch new StopWatch(); stopWatch.start(); SpringApplicationRunListeners listeners getRunListeners(args); listeners.starting(); ApplicationArguments applicationArguments new DefaultApplicationArguments(args); ConfigurableEnvironment environment prepareEnvironment(listeners, applicationArguments); printBanner(environment); ConfigurableApplicationContext context createApplicationContext(); prepareContext(context, environment, listeners, applicationArguments, printedBanner); refreshContext(context); afterRefresh(context, applicationArguments); stopWatch.stop(); listeners.started(context); callRunners(context, applicationArguments); listeners.running(context);面试时注意把refreshContext和callRunners分开说。refreshContext是 Spring 容器刷新你之前在Configuration里定义的 Bean 都是在这个阶段被实例化的可以理解为 Spring Framework 的老流程。afterRefresh是一个空实现的扩展点留给子类。callRunners则在容器刷新完成之后执行它调用的是ApplicationRunner和CommandLineRunner。高频追问点ApplicationRunner和CommandLineRunner有什么区别区别只在参数封装。CommandLineRunner的run(String... args)接收的是原始的命令行参数数组你需要自己解析ApplicationRunner的run(ApplicationArguments args)接收的是封装好的对象支持getOptionNames()、getNonOptionArgs()等方法更方便拿--keyvalue这类参数。两者都定义成 Bean 就会执行执行顺序可以通过Order(n)控制数字越小越先执行。我在项目里的习惯是预热本地缓存、初始化定时任务、检查第三方依赖连通性全部放在ApplicationRunner里做而不是放在PostConstruct里。原因很简单PostConstruct执行的时候整个应用还没完全启动日志上下文、Actuator 健康检查都还没就绪一旦RedisTemplate依赖的连接池初始化失败你连个完整的错误信息都很难抓到。放到ApplicationRunner里跑至少能保证容器环境是完整的。2.3 内嵌Tomcat的加载时机内嵌容器是 Spring Boot 的招牌能力面试也常考。核心逻辑在ServletWebServerApplicationContext。ServletWebServerApplicationContext是GenericWebApplicationContext的子类它在onRefresh()阶段会调用createWebServer()。createWebServer()先从容器里找ServletWebServerFactorySpring Boot 的ServletWebServerFactoryAutoConfiguration会根据 classpath 上的依赖自动装配TomcatServletWebServerFactory、JettyServletWebServerFactory或UndertowServletWebServerFactory。拿到 factory 之后调用getWebServer()这一步会创建真正的 Tomcat 对象、设置端口、添加 Connector、启动 Tomcat。换句话说内嵌 Tomcat 是在refresh()刷新的早期onRefresh就被启动的不是等到run()最后才启动。Web 请求真正可以进来是在refresh()完成之前。所以在PostConstruct的回调里做需要 Web 能力的事情时机上是有点赌运气的。2.4 启动慢的定位思路面试题不会只问原理大概率还会延伸出一个实际场景项目启动特别慢怎么排查我的排查顺序是在ApplicationRunner里逐个打印关键组件的初始化耗时。用-Dspring.jmx.enabledfalse关掉 JMX去掉不必要的管理端点。检查有没有大包的自动配置被误加载例如一个纯 Web 项目引入了spring-boot-starter-data-mongodb但没配连接信息MongoDB 的自动配置会做连接探测直接拖慢启动。复查日志里的Started Application in X seconds结合debugtrue的自动配置报告看有没有非预期的 Positive matches。第二个问题我可以提供一个实际案例。有个项目的启动时间从十几秒涨到近一分钟最后查出来是类路径扫描范围太大。项目里一个ComponentScan写在了公共模块上把几万个类全部扫了一遍。Spring Boot 对ComponentScan的默认包扫描是按启动类所在包往下扫的如果你把启动类放得很靠上比如放在com.example根包扫描范围就可能失控。尽量把启动类放在项目包的顶层但不要放在组织名这种层级com.example.project.Application比com.example.Application更合适。3. Import与条件装配自定义Starter之前必须吃透的底子3.1 Import的三种用法Import是 Spring 里非常核心但容易被忽略的注解自动配置机制的底层就是它。面试如果只问Import通常会拆成三个层次第一种直接导入普通的Configuration类或普通类。比如Import({MyConfiguration.class})这种方式最简单适合写死某一个配置类的情况。第二种导入ImportSelector的实现类。ImportSelector接口只有一个方法selectImports(AnnotationMetadata importingClassMetadata)返回的是要注册到容器的 Bean 定义名称数组。这个方法的参数AnnotationMetadata可以拿到Import注解所在类上的所有其他注解信息这就给了动态判断的空间。public class MyImportSelector implements ImportSelector { Override public String[] selectImports(AnnotationMetadata importingClassMetadata) { if (importingClassMetadata.hasAnnotation(com.example.EnableFeature)) { return new String[] { com.example.FeatureConfiguration }; } return new String[0]; } }第三种导入ImportBeanDefinitionRegistrar。这个更底层可以直接操作BeanDefinitionRegistry手动注册BeanDefinition。这种方式最灵活也最复杂Spring Boot 里很多条件化和动态注册的逻辑就是通过它来实现的。3.2 自己写一个Conditional条件注解理解了Import和条件装配就可以动手实现一个自定义的Conditional注解。这个技能在写公共组件、第三方 starter 时非常常用。实现步骤很简单写一个类实现Condition接口在matches方法中写判断逻辑。public class OnLinuxCondition implements Condition { Override public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { String osName context.getEnvironment().getProperty(os.name); return osName ! null osName.toLowerCase().contains(linux); } }使用的时候直接挂到配置类或Bean方法上Configuration public class PlatformConfiguration { Bean Conditional(OnLinuxCondition.class) public LinuxCommand linuxCommand() { return new LinuxCommand(); } }建议真正动手写过一次能理解ConditionContext里能拿到的环境变量、BeanFactory、ClassLoader比单纯背ConditionalOnProperty的用法收获大得多。3.3 配置类的CGLIB代理与Bean重复调用这是一个非常高频的坑也是一个很好的面试题Configuration类里两个Bean方法都调用了同一个Bean方法那么 bean 实例是同一个吗答案取决于proxyBeanMethods属性。Configuration默认proxyBeanMethods trueSpring 会用 CGLIB 为配置类创建代理。当在一个Bean方法内部调用另一个Bean方法时走的不是真实方法而是代理逻辑Spring 会直接返回容器里的单例 Bean不会重复创建。如果把proxyBeanMethods设为false配置类进入 Lite 模式不再被 CGLIB 代理每次调用返回的都是一个新的对象。什么时候用proxyBeanMethods false如果你的配置类只是简单地声明Bean方法不存在方法之间的互相调用可以关掉代理减少 CGLIB 的生成开销启动会更快一点。Spring Boot 内部很多自动配置类都挂了Configuration(proxyBeanMethods false)算是官方推荐的习惯。实际项目里踩过一个具体的坑把Configuration写成了Component然后两个Bean方法互相调用。Component是不做 CGLIB 增强的每次调用都返回新实例导致两个 Bean 引用的依赖对象不一致排查了半天才发现是这类注解用错导致的。3.4 自定义Starter的设计顺序如果你想做一个自定义 starter推荐按下面这个顺序来能少走弯路先定功能边界。比如做一个“基于 Redis 的分布式锁 starter”先想清楚暴露给使用方的 API 是什么而不是一上来就写配置类。写一个自动配置类在类上挂条件注解。比如ConditionalOnClass(RedisTemplate.class)、ConditionalOnProperty(prefix my.lock, name enabled, havingValue true)。提供一个ConfigurationProperties类用于读取外部配置。在AutoConfiguration.imports里注册自动配置类。记得让自动配置类支持AutoConfigureBefore/AutoConfigureAfter控制与其他配置的先后顺序。更关键的一点自动配置类不要直接做业务逻辑判断把判断交给条件注解和配置属性这样使用方可以通过配置开关控制是否启用而不是被迫删除依赖。4. Spring Boot集成Redis Stream订单消息拉取的正确姿势4.1 为什么选Redis Stream而不是List现在很多项目用 Redis 做消息队列最常听到的选型对比是 Redis List 和 Redis Stream。List 的做法是LPUSHBRPOP实现简单但它有一个天然缺陷消费时没有消费者组的概念。多个消费者同时BRPOP同一个 List 时每个消息只会被一个消费者取走这其实相当于“竞争消费”如果你想要“广播给所有消费者”或者“按组分配消费”List 就很难做。Redis Stream 是 Redis 5.0 引入的数据结构专门用来支持消息队列场景。它在设计上解决了几个问题多个消费者可以组成一个消费者组组内消息会被分担给不同消费者。每一条消息都有唯一的 ID消费完成后可以显式 ACK。消费过的消息会进入 Pending Entries ListPEL如果消费者挂了没 ACK消息不会被丢可以重新读取。支持XREADGROUP、XAUTOCLAIM等命令可以对超时未确认的消息做“认领”。所以如果你想做一套“不引入 RabbitMQ/Kafka 但又要一定可靠性”的轻量消息队列Redis Stream 是很合适的选择。尤其是预约服务系统这种场景下单、支付、预约通知、服务完成回写这些事件量不大但对可靠性有基本要求用 Redis Stream 能省掉额外维护一套 MQ 的成本。4.2 消息必达的三角色模型要理解 Redis Stream 的消费模型可以把它拆成三个角色Stream消息流本身用 key 区分。Consumer Group消费者组。组内共用一个“游标”last_delivered_id新消息只会被组内一个消费者拿一次不会重复分发。Consumer组内的消费者每个消费者有独立的 PEL记录自己取到但还没 ACK 的消息。关键命令如下# 创建流并追加消息 XADD cooking:order * userId 1001 type CREATE_ORDER # 创建消费者组 XGROUP CREATE cooking:order cooking-order-group 0 # 从消费者组读取消息block 表示没有消息时阻塞等待 XREADGROUP GROUP cooking-order-group consumer-1 COUNT 1 BLOCK 5000 STREAMS cooking:order 是特殊 ID表示“只读取从未投递给其他消费者的新消息”。如果想读自己 PEL 中已经投递但未 ACK 的历史消息可以用0作为 ID。处理完成之后要显式 ACKXACK cooking:order cooking-order-group message-id等所有消费者都确认消息之后消息才会从全组的 PEL 中消失。4.3 基于StreamMessageListenerContainer的消费端实现Spring Data Redis 从 2.3 开始支持 Redis Stream并且提供了一个非常实用的类StreamMessageListenerContainer。它是一个长轮询的消息监听容器类似于 Kafka 的MessageListenerContainer底层会不断通过XREADGROUP拉取消息。基础用法是定义一个配置类Configuration public class RedisStreamConfig { Bean public StreamMessageListenerContainerString, MapRecordString, String, String streamMessageListenerContainer( RedisConnectionFactory redisConnectionFactory) { StreamMessageListenerContainerOptionsString, MapRecordString, String, String options StreamMessageListenerContainerOptions .builder() .pollTimeout(Duration.ofSeconds(2)) .keySerializer(RedisSerializer.string()) .build(); StreamMessageListenerContainerString, MapRecordString, String, String container StreamMessageListenerContainer.create(redisConnectionFactory, options); container.receive( Consumer.from(cooking-order-group, consumer-1), StreamOffset.create(cooking:order, ReadOffset.lastConsumed()), message - { MapString, String body message.getValue(); System.out.println(收到消息: message.getId() body); }); container.start(); return container; } }这里有几个需要注意的细节。第一消费者的名字不能写死。如果同一份代码部署了多个实例每个实例的Consumer.from里的 consumer name 都叫consumer-1那么这两个实例会共享同一个消费者身份消息不会被分散消费。实际上生产环境至少部署两个实例时consumer name 应该带上实例标识比如${spring.application.name}-${random.uuid}或者直接用InetAddress.getLocalHost().getHostName()。第二ReadOffset.lastConsumed()表示从组内最后消费的位置继续读。如果你第一次创建消费者组就用了ReadOffset.lastConsumed()而组内游标还没有任何记录新消息进来是可以读到的。如果你用ReadOffset.from(0)它会从头把历史消息都读一遍这个要小心。第三StreamMessageListenerContainer的receive方法里有重载版本可以传StreamListener也可以传ConsumerRecord。实际项目里我习惯在StreamListener的onMessage里做业务处理因为可以拿到Record里的StreamMessageId。4.4 消费端最容易踩的三个坑坑一消息处理失败但忘记 ACK。这是最隐蔽的问题。StreamMessageListenerContainer默认会在收到消息后立即 ACK 吗实际上不一定。如果你用的是receive(Consumer, StreamOffset, StreamListener)这种 APISpring 默认在StreamListener.onMessage正常执行完毕后会 ACK。但如果你的onMessage里抛了异常Spring 会把消息放回容器进入重试状态重试几次之后如果还失败消息就一直在 PEL 里逐渐堆积。所以我在生产环境一定会监控消费者的 pending 数量一旦持续增长就要查是不是有消费失败的消息卡住了。坑二重复消费不幂等。Redis Stream 的“至少一次”语义在极端场景下可能变成重复投递。消费者处理完消息之后在 ACK 之前挂了消息还在 PEL 里重新拉取或者超时认领后会被再次消费。所以消费端的业务逻辑必须做幂等。比如预约服务里的“创建订单”消息处理函数里先查订单号是否已存在已存在就直接返回不要重复插入数据库。坑三消费者组的创建时机。XGROUP CREATE不能在 Stream 不存在时创建。如果你启动应用时 Redis 里还没有cooking:order这个 keyXGROUP CREATE会报错“BUSYGROUP”或者“NOGROUP”。Spring Data Redis 的容器启动时不会自动建组你需要自己保证组存在。我的做法是在启动类的ApplicationRunner里做一个初始化方法public void initStreamGroup(String streamKey, String groupName) { try { stringRedisTemplate.opsForStream().createGroup(streamKey, groupName, ReadOffset.from(0)); } catch (RedisSystemException e) { log.info(group already exists: {}, e.getMessage()); } }第一次启动时如果没有 Stream可以先用XADD塞一条“初始化消息”再建组或者直接判断hasKey后决定是否建组。这一层初始化逻辑不算复杂但往往会漏。5. 从《上门烹饪预约服务系统》看Spring Boot项目的隐藏雷区5.1 Transactional失效的四大场景很多预约类、订单类系统里事务用得非常多。但面试也好、实际开发也好Transactional失效是出现频率最高的问题之一。常见失效场景有四个场景一同类内部调用。这个是最经典的。OrderService.save()方法加了事务内部调用了同一个类的另一个方法updateStock()updateStock()也加了Transactional但调用发生时走的是this.updateStock()没有经过 Spring 的代理对象事务注解完全不起作用。解决办法是把事务方法拆到另一个类里或者通过注入自己的代理对象调用。场景二方法不是 public。Spring AOP 默认基于 JDK 动态代理或 CGLIB非 public 方法不会拦截。所以Transactional只能加在 public 方法上。场景三异常被吞掉。事务切面默认只对RuntimeException和Error回滚Exception默认不回滚。如果方法里 catch 了异常没往外抛或者抛出的是普通Exception事务自然不回滚。Transactional public void createOrder(Order order) { orderDao.insert(order); try { paymentService.pay(order); } catch (Exception e) { // 这里吞掉异常事务不会回滚订单已入库但支付失败 log.error(pay failed, e); } }你想让自定义异常也触发回滚需要在注解上指定Transactional(rollbackFor Exception.class)。场景四数据库引擎不支持事务。MySQL 的 MyISAM 引擎不支持事务表结构里用了 MyISAM加再多注解也白搭。排查时先确认表是 InnoDB。5.2 LocalDateTime与Jackson的序列化之坑预约系统里时间字段特别多预约时间、上门时间、下单时间、完成时间。Java 8 的LocalDateTime非常常用但如果你不对序列化做任何配置前端拿到的往往是数组格式的 JSON比如[2025, 3, 16, 10, 30]需要自己拼才能变成可读格式。正确做法是统一在配置里加一个Jackson2ObjectMapperBuilderCustomizerBean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializerByType(LocalDateTime.class, new LocalDateTimeSerializer( DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); builder.deserializerByType(LocalDateTime.class, new LocalDateTimeDeserializer( DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }; }前端传参时也要注意GET请求的参数或者application/x-www-form-urlencoded表单里的时间字符串默认是不能直接绑定到LocalDateTime的。需要在Controller的方法参数上加DateTimeFormat(pattern yyyy-MM-dd HH:mm:ss)或者全局注册ConverterString, LocalDateTime。这个坑在小项目里很常见因为本地测试的时候前端工程师一般会传标准的 ISO 格式恰好LocalDateTime默认识别 ISO 格式但一旦换成yyyy-MM-dd HH:mm:ss就挂了。提前统一格式能省很多联调时间。5.3 分层与事务的边界Controller别碰事务预约系统分层一般比较标准Controller - Service - Mapper/Dao。面试可能会问“Controller 方法上能加Transactional吗”理论上可以但绝不推荐。事务是服务层的职责不是接口层的职责。原因有两个Controller 的职责是接收参数、校验参数、转换响应它不应该关心数据一致性。Controller 里的参数校验、权限判断如果都在事务中执行会拉长事务的持有时间数据库连接被长时间占用并发一高就会拖垮连接池。实际开发中我见过的更隐蔽的问题是Transactional加在 Service 方法上但service.save()里调用了另一个 service 的远程接口。如果远程接口响应慢数据库事务一直不提交数据库连接池被占满整个应用就失去了响应。事务方法里只做本地数据库操作远程调用、消息发送等容易阻塞的 I/O 操作要么放到事务提交后做要么通过事件监听机制在TransactionalEventListener里处理。5.4 上线前检查清单服务类项目上线前以下检查项是我每次都会过的虽然琐碎但能救命的点Profile 切换确认application-prod.properties没有把debugtrue写进去避免生产环境打印自动配置报告和 SQL。日志级别生产环境建议logging.level.rootINFO不要用DEBUG否则日志量巨大磁盘会被打满。Actuator 暴露范围management.endpoints.web.exposure.include不要配成*尤其是shutdown和env这类敏感端点。连接池参数HikariCP 里maximum-pool-size、connection-timeout、max-lifetime三个参数要配合数据库实际连接上限设置max-lifetime建议比数据库的wait_timeout短一点。Spring Boot 版本升级后检查升级版本之后跑一遍启动盯住debugtrue的自动配置报告看有没有条件匹配发生变化的自动配置类。预约系统的核心还是“订单状态的流转”任何一环出错都会影响用户体验。与其把精力花在堆功能上不如先把 Spring Boot 的这一层地基打扎实事务、序列化、连接池、消息队列每一样都是线上事故的高发区。最后分享一个小技巧面试准备阶段别只看总结性文章花一个下午的时间把spring-boot-autoconfigure的源码拉下来搜AutoConfiguration.imports再跟着SpringApplication.run()断点走一遍比背十个面试文档都有用。遇到过的问题自己动手验证过面试时才说得清楚。