date_add本身不导致时区异常，而是与timestamp字段、会话时区、系统时区叠加暴露隐式转换问题：datetime按字面计算，timestamp则先转本地时区再运算；jdbc的servertimezone参数仅影响驱动解析，不改变服务端逻辑；curdate()/now()受会话时区直接影响，需统一时区源头。
不是 DATE_ADD 本身导致时区异常，而是它和 TIMESTAMP 字段、连接时区、系统时区三者叠加后暴露了隐式转换逻辑。
DATE_ADD 对 DATETIME 和 TIMESTAMP 的行为差异
DATE_ADD 本身不主动做时区转换，但它的输入值解释方式取决于字段类型：
-
DATETIME类型存储的是“字面时间”，DATE_ADD 直接按字符串逻辑加减（如DATE_ADD('2023-01-01 12:00:00', INTERVAL 1 HOUR)→'2023-01-01 13:00:00'），完全不涉及时区 -
TIMESTAMP类型存储的是 UTC 时间戳，MySQL 在写入/读取时会根据当前会话时区自动转成本地时间再显示；DATE_ADD 的参数若来自TIMESTAMP字段，实际参与计算的是“已转成会话时区的本地值”，而非原始 UTC 值 - 如果会话时区是
+00:00，而系统时间是+08:00，你看到的TIMESTAMP值比真实业务时间快 8 小时——DATE_ADD 在这个基础上再加 1 小时，结果就偏了 9 小时
jdbc 连接参数 serverTimezone=xxx 怎么影响 DATE_ADD
这个参数只控制 JDBC 驱动如何解释从 MySQL 返回的 TIMESTAMP 值，并不改变服务端计算逻辑。但它会制造一种“错觉”：
- 没配
serverTimezone：驱动默认用 JVM 本地时区解析TIMESTAMP，若 JVM 是Asia/Shanghai，而 MySQL 服务端时区是UTC，就会把一个存为2023-01-01 04:00:00（UTC）的值，当成2023-01-01 12:00:00（本地）来用 —— DATE_ADD 就在这个错误基础上算 - 配了
serverTimezone=UTC但 MySQL 实际是+08:00：驱动强行按 UTC 解析，把2023-01-01 12:00:00（服务端显示值）当作 UTC 时间，还原成2023-01-02 04:00:00（本地），再传给 DATE_ADD，结果更离谱 - 真正要对齐的不是驱动参数，而是让 MySQL 服务端、操作系统、JVM 三者时区一致，或至少明确知道各自偏差多少
为什么在命令行里执行 DATE_ADD 看不出问题？
因为命令行客户端（mysql CLI）默认使用系统时区作为会话时区，且不进行 Java 那样的二次解析；它展示的 TIMESTAMP 值就是服务端“按当前会话时区换算后”的结果，DATE_ADD 输入输出都在同一套规则下，偏差被掩盖了。
但应用层（Spring Boot / MyBatis）拿到的是 JDBC 驱动封装后的 java.time.LocalDateTime 或 Timestamp，它已经按 serverTimezone 做过一次转换，再喂给 DATE_ADD 就成了“二次转换+计算”，错误被放大。
最易被忽略的点：CURDATE() 和 NOW() 的隐式时区绑定
这两个函数返回值受会话时区直接影响，而它们常被用作 DATE_ADD 的基准：
-
DATE_ADD(CURDATE(), INTERVAL 1 DAY)看似安全，但如果会话时区是UTC，而你要查的是Asia/Shanghai的“今天”，CURDATE() 返回的就是 UTC 的“今天”，比上海早 8 小时 - 更隐蔽的是
NOW()：它返回带时分秒的当前时间，但如果你的表字段是TIMESTAMP，NOW() 返回值会先被转成 UTC 存储，再被 DATE_ADD 拿来算——中间多了一次隐式转换 - 解决方案不是避免用 NOW()，而是统一所有环节的时区源头：要么全用
DATETIME+ 显式时区处理，要么确保default_time_zone、serverTimezone、JVMuser.timezone三者严格一致
