升级至Spring Boot 3.3.10后与MySQL交互时出现随机UTC时区问题

这种随机的时区问题确实让人挠头，尤其是CI环境跑完全没问题，但本地开发环境的集成测试时不时抽风的情况——大概率是环境差异或者测试执行过程中的线程/上下文干扰在搞鬼。结合你已经做的排查，我整理了几个可能的方向：

1. Spring Boot 3.3.10+的上下文/线程池变化 #

Spring Boot在3.3.10版本可能调整了上下文加载逻辑，或者@SpringBootTest的上下文缓存策略有更新。你在@SpringBootApplication类里加的静态块，理论上会在类加载时执行，但如果测试中存在：

• 多测试类并行加载不同上下文（比如有的测试用了自定义配置）
• 某些测试用@DirtiesContext触发了上下文重建
  这时候可能出现静态块执行时机和线程默认时区不同步的情况，导致部分线程的时区没被设为UTC。

另外，新版本的Spring Boot可能对内部线程池（比如异步任务、测试执行线程）的默认时区处理有变化，部分线程没有同步JVM的默认时区，操作数据库时就会用系统时区，出现随机失败。

2. MySQL连接池的会话状态泄漏 #

你用了tomcat-dbcp，虽然配置了connectionTimezone=UTC，但连接池的连接可能存在时区状态泄漏：比如某个测试不小心执行了SET time_zone = 'Asia/Shanghai'这类操作，归还连接到池里后，后续测试复用这个连接时就会用错误的时区，导致随机失败。

可以试试在连接池配置里加一行initSQL=SET time_zone = '+00:00'，强制每个连接被取出时都重置会话时区，彻底避免连接复用带来的状态污染。

3. 测试框架的并行执行干扰 #

如果你的集成测试用了并行执行（比如JUnit 5的@Execution(ExecutionMode.CONCURRENT)），不同测试线程的时区可能没被统一管控。TimeZone.setDefault()是JVM全局生效的，但如果某个测试线程在执行时修改了默认时区（比如测试时区转换的用例），执行完没还原，就会影响其他并行跑的测试，出现随机失败。

建议检查测试类的并行配置，或者在每个测试的@BeforeEach和@AfterEach里显式设置并还原时区，确保每个测试的时区环境都是干净的：

private TimeZone originalTimeZone;

@BeforeEach
void setUpTimeZone() {
    originalTimeZone = TimeZone.getDefault();
    TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
}

@AfterEach
void restoreTimeZone() {
    TimeZone.setDefault(originalTimeZone);
}

4. Hibernate/JPA的时区映射逻辑变化 #

Spring Boot 3.3.10可能升级了Hibernate的版本，或者调整了java.time类型的映射策略。如果你的代码里混合用了java.util.Date和java.time.LocalDateTime这类新旧日期类，新版本的Hibernate可能对时区的处理逻辑不同，在上下文切换或多线程操作时出现不一致。

可以强制Hibernate用UTC时区处理所有日期类型，在application-test.properties里加：

spring.jpa.properties.hibernate.jdbc.time_zone=UTC

这个配置会让Hibernate直接绕过JVM默认时区，强制用UTC和MySQL交互，能避免很多隐性的时区问题。

5. 本地MySQL的全局时区残留影响 #

虽然你设置了会话时区为UTC，但本地MySQL的全局时区或者系统级时区可能在某些隐式操作中被读取。如果你用的是本地安装的MySQL而非Docker镜像，还可能出现时区表加载不完整，或者其他进程修改了系统时区的情况（比如系统自动更新时区、其他应用改了时间设置）。

可以在MySQL里执行以下命令确认全局时区：

SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;

如果全局时区不是UTC，直接在MySQL配置文件里加default-time-zone = '+00:00'，重启MySQL服务彻底搞定。

快速定位小技巧 #

你可以在每个测试的前后打印当前JVM时区和MySQL会话时区，把日志打出来：

// 打印JVM时区
System.out.println("JVM TimeZone: " + TimeZone.getDefault().getID());
// 打印MySQL会话时区
String sql = "SELECT @@SESSION.time_zone";
String sessionTz = jdbcTemplate.queryForObject(sql, String.class);
System.out.println("MySQL Session TimeZone: " + sessionTz);

当测试失败时，对比成功和失败的日志，就能快速定位是JVM时区变了，还是MySQL连接时区出了问题，缩小排查范围。

这些方向应该能帮你锁定问题，毕竟随机问题的本质都是有某个可变因素没被控制住，把每个可能的状态都固定下来，问题就会暴露出来了。

内容来源于stack exchange