企业官网建设流程全解析

开头

最近陆续帮几个朋友做面试复盘，发现一个很有意思的现象：很多人背了一大堆“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。如果你自己定义了DataSource，Spring Boot 就不会再用它默认的DataSource。
• @ConditionalOnProperty：配合application.properties里的配置项判断。比如@ConditionalOnProperty(prefix = "spring.redis", name = "enabled", havingValue = "true")。
• @ConditionalOnWebApplication：当前是不是 Web 应用。这个在区分 WebMvc 和 WebFlux 配置时很关键。

理解了条件装配，就不难想明白一个经典面试题：为什么你在项目里自定义了一个ObjectMapper的@Bean，Spring Boot 不会因此报冲突？因为JacksonAutoConfiguration里有一个@ConditionalOnMissingBean，一旦容器里已经存在ObjectMapper，它默认的ObjectMapper就不再创建了。

这一点在定位“我的配置为什么不生效”的时候特别有用。我见过不少同事排查问题，查了半天发现自己写的RestTemplate配置没生效，打开自动配置报告一看，原因就是某个 starter 里的@ConditionalOnMissingBean被容器里另一个同名 Bean 先占了。

1.4 调试自动配置：打开报告看真相

如果你不想对着源码猜，Spring Boot 提供了一个非常实用的调试开关：在application.properties里加一行debug=true，启动的时候日志里会打印一份完整的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 阶段，忽略了构造方法里做的前置工作，但恰恰是构造方法里的逻辑决定了后面怎么走。

构造方法里最重要的三件事：

1. 推断应用类型。通过WebApplicationType.deduceFromClasspath()判断当前是 SERVLET 应用（有javax.servlet.Servlet和ConfigurableWebApplicationContext）、REACTIVE 应用（有ReactiveStreams和DispatcherHandler）还是 NONE（非 Web）。
2. 加载 ApplicationContextInitializer 和 ApplicationListener。这两个都是从spring.factories里加载的。它们可以在容器刷新前对ConfigurableApplicationContext做定制，比如往环境中加入自定义的属性源。
3. 推断主配置类。通过堆栈信息找到包含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()等方法，更方便拿--key=value这类参数。两者都定义成 Bean 就会执行，执行顺序可以通过@Order(n)控制，数字越小越先执行。

我在项目里的习惯是：预热本地缓存、初始化定时任务、检查第三方依赖连通性，全部放在ApplicationRunner里做，而不是放在@PostConstruct里。原因很简单，@PostConstruct执行的时候整个应用还没完全启动，日志上下文、Actuator 健康检查都还没就绪，一旦RedisTemplate依赖的连接池初始化失败，你连个完整的错误信息都很难抓到。放到ApplicationRunner里跑，至少能保证容器环境是完整的。

2.3 内嵌Tomcat的加载时机

内嵌容器是 Spring Boot 的招牌能力，面试也常考。核心逻辑在ServletWebServerApplicationContext。

ServletWebServerApplicationContext是GenericWebApplicationContext的子类，它在onRefresh()阶段会调用createWebServer()。createWebServer()先从容器里找ServletWebServerFactory，Spring Boot 的ServletWebServerFactoryAutoConfiguration会根据 classpath 上的依赖自动装配TomcatServletWebServerFactory、JettyServletWebServerFactory或UndertowServletWebServerFactory。拿到 factory 之后调用getWebServer()，这一步会创建真正的 Tomcat 对象、设置端口、添加 Connector、启动 Tomcat。

换句话说，内嵌 Tomcat 是在refresh()刷新的早期（onRefresh）就被启动的，不是等到run()最后才启动。Web 请求真正可以进来，是在refresh()完成之前。所以在@PostConstruct的回调里做需要 Web 能力的事情，时机上是有点赌运气的。

2.4 启动慢的定位思路

面试题不会只问原理，大概率还会延伸出一个实际场景：项目启动特别慢，怎么排查？

我的排查顺序是：

1. 在ApplicationRunner里逐个打印关键组件的初始化耗时。
2. 用-Dspring.jmx.enabled=false关掉 JMX，去掉不必要的管理端点。
3. 检查有没有大包的自动配置被误加载，例如一个纯 Web 项目引入了spring-boot-starter-data-mongodb但没配连接信息，MongoDB 的自动配置会做连接探测，直接拖慢启动。
4. 复查日志里的Started Application in X seconds，结合debug=true的自动配置报告看有没有非预期的 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 = true，Spring 会用 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，推荐按下面这个顺序来，能少走弯路：

1. 先定功能边界。比如做一个“基于 Redis 的分布式锁 starter”，先想清楚暴露给使用方的 API 是什么，而不是一上来就写配置类。
2. 写一个自动配置类，在类上挂条件注解。比如@ConditionalOnClass(RedisTemplate.class)、@ConditionalOnProperty(prefix = "my.lock", name = "enabled", havingValue = "true")。
3. 提供一个@ConfigurationProperties类，用于读取外部配置。
4. 在AutoConfiguration.imports里注册自动配置类。
5. 记得让自动配置类支持@AutoConfigureBefore/@AutoConfigureAfter，控制与其他配置的先后顺序。

更关键的一点：自动配置类不要直接做业务逻辑判断，把判断交给条件注解和配置属性，这样使用方可以通过配置开关控制是否启用，而不是被迫删除依赖。

4. Spring Boot集成Redis Stream：订单消息拉取的正确姿势

4.1 为什么选Redis Stream而不是List

现在很多项目用 Redis 做消息队列，最常听到的选型对比是 Redis List 和 Redis Stream。List 的做法是LPUSH+BRPOP，实现简单，但它有一个天然缺陷：消费时没有消费者组的概念。多个消费者同时BRPOP同一个 List 时，每个消息只会被一个消费者取走，这其实相当于“竞争消费”，如果你想要“广播给所有消费者”或者“按组分配消费”，List 就很难做。

Redis Stream 是 Redis 5.0 引入的数据结构，专门用来支持消息队列场景。它在设计上解决了几个问题：

• 多个消费者可以组成一个消费者组，组内消息会被分担给不同消费者。
• 每一条消息都有唯一的 ID，消费完成后可以显式 ACK。
• 消费过的消息会进入 Pending Entries List（PEL），如果消费者挂了没 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。

处理完成之后，要显式 ACK：

XACK 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 StreamMessageListenerContainer<String, MapRecord<String, String, String>> streamMessageListenerContainer( RedisConnectionFactory redisConnectionFactory) { StreamMessageListenerContainerOptions<String, MapRecord<String, String, String>> options = StreamMessageListenerContainerOptions .builder() .pollTimeout(Duration.ofSeconds(2)) .keySerializer(RedisSerializer.string()) .build(); StreamMessageListenerContainer<String, MapRecord<String, String, String>> container = StreamMessageListenerContainer.create(redisConnectionFactory, options); container.receive( Consumer.from("cooking-order-group", "consumer-1"), StreamOffset.create("cooking:order", ReadOffset.lastConsumed()), message -> { Map<String, 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，也可以传Consumer<Record>。实际项目里我习惯在StreamListener的onMessage里做业务处理，因为可以拿到Record里的StreamMessageId。

4.4 消费端最容易踩的三个坑

坑一：消息处理失败但忘记 ACK。这是最隐蔽的问题。StreamMessageListenerContainer默认会在收到消息后立即 ACK 吗？实际上不一定。如果你用的是receive(Consumer, StreamOffset, StreamListener)这种 API，Spring 默认在StreamListener.onMessage正常执行完毕后会 ACK。但如果你的onMessage里抛了异常，Spring 会把消息放回容器，进入重试状态，重试几次之后如果还失败，消息就一直在 PEL 里，逐渐堆积。所以我在生产环境一定会监控消费者的 pending 数量，一旦持续增长，就要查是不是有消费失败的消息卡住了。

坑二：重复消费不幂等。Redis Stream 的“至少一次”语义在极端场景下可能变成重复投递。消费者处理完消息之后在 ACK 之前挂了，消息还在 PEL 里，重新拉取或者超时认领后会被再次消费。所以消费端的业务逻辑必须做幂等。比如预约服务里的“创建订单”消息，处理函数里先查订单号是否已存在，已存在就直接返回，不要重复插入数据库。

坑三：消费者组的创建时机。XGROUP CREATE不能在 Stream 不存在时创建。如果你启动应用时 Redis 里还没有cooking:order这个 key，XGROUP 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]，需要自己拼才能变成可读格式。

正确做法是统一在配置里加一个Jackson2ObjectMapperBuilderCustomizer：

@Bean 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")，或者全局注册Converter<String, LocalDateTime>。

这个坑在小项目里很常见，因为本地测试的时候前端工程师一般会传标准的 ISO 格式，恰好LocalDateTime默认识别 ISO 格式，但一旦换成yyyy-MM-dd HH:mm:ss就挂了。提前统一格式能省很多联调时间。

5.3 分层与事务的边界：Controller别碰事务

预约系统分层一般比较标准：Controller -> Service -> Mapper/Dao。面试可能会问：“Controller 方法上能加@Transactional吗？”

理论上可以，但绝不推荐。事务是服务层的职责，不是接口层的职责。原因有两个：

1. Controller 的职责是接收参数、校验参数、转换响应，它不应该关心数据一致性。
2. Controller 里的参数校验、权限判断如果都在事务中执行，会拉长事务的持有时间，数据库连接被长时间占用，并发一高就会拖垮连接池。

实际开发中我见过的更隐蔽的问题是：@Transactional加在 Service 方法上，但service.save()里调用了另一个 service 的远程接口。如果远程接口响应慢，数据库事务一直不提交，数据库连接池被占满，整个应用就失去了响应。事务方法里只做本地数据库操作，远程调用、消息发送等容易阻塞的 I/O 操作，要么放到事务提交后做，要么通过事件监听机制在@TransactionalEventListener里处理。

5.4 上线前检查清单

服务类项目上线前，以下检查项是我每次都会过的，虽然琐碎但能救命的点：

• Profile 切换：确认application-prod.properties没有把debug=true写进去，避免生产环境打印自动配置报告和 SQL。
• 日志级别：生产环境建议logging.level.root=INFO，不要用DEBUG，否则日志量巨大，磁盘会被打满。
• Actuator 暴露范围：management.endpoints.web.exposure.include不要配成*，尤其是shutdown和env这类敏感端点。
• 连接池参数：HikariCP 里maximum-pool-size、connection-timeout、max-lifetime三个参数要配合数据库实际连接上限设置，max-lifetime建议比数据库的wait_timeout短一点。
• Spring Boot 版本升级后检查：升级版本之后跑一遍启动，盯住debug=true的自动配置报告，看有没有条件匹配发生变化的自动配置类。

预约系统的核心还是“订单状态的流转”，任何一环出错都会影响用户体验。与其把精力花在堆功能上，不如先把 Spring Boot 的这一层地基打扎实，事务、序列化、连接池、消息队列，每一样都是线上事故的高发区。

最后分享一个小技巧：面试准备阶段别只看总结性文章，花一个下午的时间，把spring-boot-autoconfigure的源码拉下来，搜AutoConfiguration.imports，再跟着SpringApplication.run()断点走一遍，比背十个面试文档都有用。遇到过的问题，自己动手验证过，面试时才说得清楚。