MySQL TIMESTAMP 默认按会话时区转UTC存储并返回，JDBC需配置serverTimezone=UTC且用OffsetDateTime交互，推荐统一用UTC存储、业务层处理时区。
MySQL 的 TIMESTAMP 字段默认按服务器时区存储，但会自动转换为 UTC 存储，并在查询时转回当前会话时区 —— 这和 Java 的 ZonedDateTime 有本质区别：ZonedDateTime 是带时区的完整时间点，而 JDBC 默认把 TIMESTAMP 当作“无时区本地时间”处理，容易出错。
理解 MySQL TIMESTAMP 的行为
MySQL TIMESTAMP 类型实际存储的是 UTC 时间戳（4 字节），但 SQL 层面表现受以下影响：
- 插入/更新时，若传入无时区时间（如
'2024-06-15 10:00:00'），MySQL 会按当前会话时区（time_zone）转成 UTC 存储； - 查询时，再将存储的 UTC 值按会话时区转回本地时间返回；
- 若会话时区是
+08:00，插入'2024-06-15 10:00:00'实际存的是2024-06-15T02:00:00Z； -
DATETIME则不自动时区转换，纯字面值存储 —— 如果你不需要自动转换，优先考虑DATETIME+ 显式时区管理。
JDBC 连接参数必须显式指定时区
即使 MySQL 服务端用 UTC，JDBC 驱动默认仍按 JVM 本地时区解析 TIMESTAMP，导致读写偏差。关键参数：
-
serverTimezone=UTC：告诉驱动 MySQL 服务器用 UTC； -
useTimezone=true（MySQL 8.0+ 可省略，但建议保留）； - 避免用
useLegacyDatetimeCode=true（已弃用，行为不可靠）； - 示例连接 URL：
jdbc:mysql://localhost:3306/test?serverTimezone=UTC&useTimezone=true。
Java 侧用 OffsetDateTime 或 Instant 更安全
ZonedDateTime 包含时区规则（如夏令时），但 JDBC 不支持直接映射到 ZonedDateTime。推荐路径：
- 读取时用
ResultSet.getObject("col", OffsetDateTime.class)—— 驱动会按连接参数的serverTimezone正确解析为带偏移的时间； - 写入时用
PreparedStatement.setObject(idx, offsetDateTime)，驱动自动转为对应时区的 UTC 时间存入； - 如需
ZonedDateTime，可在应用层转换：offsetDateTime.atZoneSameInstant(ZoneId.of("Asia/Shanghai"))； - 避免用
Timestamp.valueOf(LocalDateTime)或rs.getTimestamp()（已过时且忽略时区）。
统一建议：存储用 UTC，业务层管时区
最佳实践不是让数据库或 JDBC 做时区推导，而是明确分工：
- MySQL 列类型用
TIMESTAMP（或更推荐DATETIME），但确保服务器、连接、应用三端都约定以 UTC 存储； - Java 中一律用
Instant或OffsetDateTime与数据库交互； - 用户展示、日志、调度等场景，再用
ZonedDateTime结合具体ZoneId转换（如Instant.now().atZone(ZoneId.systemDefault())）； - 测试时故意改 JVM 时区（
-Duser.timezone=America/New_York），验证读写是否仍保持逻辑一致。
不复杂但容易忽略：时区问题不在某一行代码，而在整个链路的约定是否统一。从建表、连接串、JDBC 调用到业务逻辑，每个环节都要明确“这个时间值到底代表哪个时区的什么时刻”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
