MySQL时区配置需三层对齐：容器TZ环境变量、/etc/localtime挂载、my.cnf中default-time-zone='+08:00'，缺一不可；JDBC连接须显式指定serverTimezone=GMT%2B8，并验证system_time_zone、global.time_zone、session.time_zone三者一致。
docker-compose.yml里必须配齐TZ、挂载localtime、显式设default-time-zone
只设TZ=Asia/Shanghai或只改my.cnf里的default-time-zone，都会失效。MySQL的system_time_zone变量读的是容器OS层时区，而time_zone变量又依赖system_time_zone做 fallback。三者缺一不可：
-
TZ=Asia/Shanghai确保容器启动时系统时区初始化正确（影响/etc/localtime软链指向） -
volumes: - /etc/localtime:/etc/localtime:ro让容器直接复用宿主机时间源，避免镜像内/usr/share/zoneinfo缺失或路径不一致 -
default-time-zone='+08:00'写在my.cnf中（不是SET PERSIST），才能让time_zone变量在会话建立前就生效，否则JDBC连接初期可能仍拿到+00:00
MySQL 8.4+ 的 default-time-zone 值不能只写 'Asia/Shanghai'
虽然Asia/Shanghai语义清晰，但在某些基础镜像（如mysql:8.4.7精简版）中，/usr/share/zoneinfo/Asia/Shanghai可能被裁剪，导致MySQL启动失败并报错：Unknown or incorrect time zone: 'Asia/Shanghai'。更稳妥的做法是用偏移量：
- 在
my.cnf中写default-time-zone='+08:00'，绕过系统时区文件依赖 - 避免使用
PRC（已废弃）、ROC等别名，它们在Alpine系镜像中基本不可用 - 若坚持用地区名，需确认镜像是否含完整
tzdata包；Debian系通常自带，Alpine需额外apk add tzdata
jdbc连接字符串必须显式指定serverTimezone
即使MySQL容器时区已正确，Spring Boot等应用仍可能因JDBC驱动默认行为出错。典型错误日志：The serverTimezone value 'UTC' is unrecognized。这不是MySQL配置问题，而是驱动在握手阶段未收到明确时区声明：
- JDBC URL里必须加
&serverTimezone=GMT%2B8（URL编码后为GMT%2B8）或&serverTimezone=Asia/Shanghai -
GMT+8比Asia/Shanghai更可靠——前者是固定偏移，后者依赖JVM的TimeZone.getAvailableIDs()结果，某些精简JRE可能不含该ID - Spring Boot 3.x默认使用MySQL Connector/J 8.3+，它对
serverTimezone参数更严格，漏配会直接拒绝连接
验证时别只查 NOW()，要分层看三个关键值
执行SELECT NOW()返回北京时间，不代表时区真对了。真正要检查的是三层一致性：
- 运行
docker exec mysql-container date：确认容器OS层输出CST或UTC+8，而非UTC - 进MySQL执行
SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;：三者应均为+08:00或SYSTEM且system_time_zone显示CST - 查
SHOW VARIABLES LIKE '%time_zone%';中的time_zone值：若为SYSTEM，说明default-time-zone未生效；若为+00:00，说明my.cnf没加载或语法错误
最容易被忽略的是system_time_zone——它只在MySQL启动时读一次，改了TZ环境变量但没重启容器，这个值就不会变。
