serverTimezone 配置错误会导致静默的8小时时间偏移，因JDBC驱动将本地时间误作serverTimezone时区处理而未报错；须确保serverTimezone、MySQL time_zone及JVM时区三者严格对齐，推荐用+08:00格式并自动化验证。
直接说结论：serverTimezone 配置错，最典型、最高发的生产事故就是时间静默偏移 8 小时——订单创建时间比实际晚/早 8 小时、定时任务在错误时间触发、报表统计日期错乱、跨时区用户看到的时间完全对不上。
为什么 serverTimezone 错会导致“静默八小时偏移”
这不是驱动报错，而是驱动“自作聪明”地做了错误换算。当 JDBC 驱动拿到 serverTimezone=UTC，但 MySQL 实际运行在 Asia/Shanghai（即 +08:00），它会把 Java 传来的 new Date()（本地 JVM 时区解释为北京时间）当作 UTC 时间来处理，再存进数据库。结果就是：你本意存的是 “2026-11-04 20:00:00 北京时间”，驱动却当成 “2026-11-04 20:00:00 UTC” 存了进去，等查出来再按北京时间展示，就变成 “2026-11-05 04:00:00”。
关键点在于：这种偏移不会抛异常，日志里也看不到警告，只有业务侧反馈“时间不对”才开始排查。
- 使用
TIMESTAMP字段时更隐蔽，因为它的存储/读取都带自动时区转换 - 用
DATETIME字段也不能幸免——只要 Java 层传的是java.util.Date或java.time.LocalDateTime，驱动仍会按serverTimezone做解析 - Spring Boot + MyBatis 环境下，
@Select返回的LocalDateTime可能被 Jackson 序列化成错误时间，前端看到的就是错的
serverTimezone 和 MySQL 的 time_zone 参数必须对齐
只改连接串不改数据库，等于单方面“宣布”一个并不存在的事实。JDBC 驱动信了你的话，但 MySQL 服务端根本没按你说的时区运行，时间链路就断了。
检查对齐的三步操作：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 查 MySQL 当前全局时区：
SELECT @@global.time_zone;—— 如果返回SYSTEM，再执行SELECT NOW();对比服务器date命令输出 - 查 JVM 启动时区：
System.getProperty("user.timezone")或启动参数加-Duser.timezone=Asia/Shanghai - 连接串中
serverTimezone必须和 MySQL 实际使用的时区一致，推荐用偏移量格式（如+08:00），避免依赖系统时区表
常见错配组合：serverTimezone=UTC + time_zone=SYSTEM（而系统是 CST），或 serverTimezone=Asia/Shanghai + MySQL 未加载时区表（导致驱动 fallback 到默认行为）。
容器化部署中容易被忽略的三层时区陷阱
本地跑得好好的，一上 K8s 就出问题，大概率栽在这三层上：
- 基础镜像时区：Alpine 默认是 UTC，CentOS 默认可能是
UTC或空，date命令显示的是容器 OS 时区，不是 MySQL 进程时区 - MySQL 容器启动时未指定
default-time-zone，导致time_zone是SYSTEM，但容器里SYSTEM就是 UTC - 应用 Pod 和 MySQL Pod 时区不一致，比如应用用了
tzdata包设成Asia/Shanghai，MySQL 却没配，serverTimezone再怎么写都是错的契约
验证方法：进 MySQL 容器执行 mysql -h 127.0.0.1 -e "SELECT @@session.time_zone, NOW();"，再进应用容器执行 java -cp app.jar YourMainClass 打印当前时间戳和时区，对比是否一致。
真正麻烦的从来不是“怎么配”，而是“配完之后没人验证它在真实环境里是否生效”。尤其当 serverTimezone 被写死在配置中心或启动脚本里，又没有配套的自动化校验（比如健康检查接口返回 SELECT NOW() 和 Java Instant.now() 的差值），这个参数就会在某个凌晨三点悄悄把所有时间相关的业务逻辑拖进坑里。
