oracle时间少8小时的根因是dbtimezone（+00:00）与jvm时区（如asia/shanghai）不一致，导致jdbc将无时区时间按jvm时区解析而自动偏移；解决方法是统一设jvm时区为gmt+00:00，而非依赖连接参数或jackson配置。
查出的时间比数据库里少8小时，先看 dbtimezone 和 jvm 时区是否对得上
oracle 默认 dbtimezone 是 +00:00（utc），而国内服务器 jvm 往往默认用系统时区（如 asia/shanghai），但 jdbc 驱动在解析 timestamp with time zone 或隐式转换 date 时，会拿 jvm 时区去“解释”数据库返回的裸时间值，结果就自动减了8小时。
验证方法：
- 查数据库：执行 SELECT DBTIMEZONE FROM DUAL;
- 查 JVM：启动时加 -XshowSettings:properties，或代码里打印 System.getProperty("user.timezone")
- 如果
DBTIMEZONE是+00:00，JVM 是Asia/Shanghai，那几乎必现 -8 小时偏差 - 如果数据库用的是
DATE类型（无时区），JDBC 仍会按 JVM 时区做本地化转换，不是“没时区就没问题” - Spring Boot 应用要注意：哪怕配置了
spring.jackson.time-zone=GMT+8，也救不了 JDBC 层的时区错位
强制 JDBC 连接串指定 serverTimezone 不起作用？那是 Oracle 驱动不认这个参数
MySQL 驱动支持 serverTimezone=Asia/Shanghai，但 Oracle 的 ojdbc8.jar 完全忽略它。Oracle 驱动只认两个关键参数：oracle.jdbc.timezoneAsRegion 和 oracle.jdbc.mapDateToTimestamp，且它们控制的是“怎么解释时间”，不是“设成哪个时区”。
- 别在连接串里写
serverTimezone—— Oracle 驱动不识别，白加 - 真正有效的是统一源头：要么改数据库时区（不推荐），要么调 JVM 时区（最常用）
- 如果必须保留
DBTIMEZONE=+00:00，又想 Java 里拿到东八区时间，就得让 JVM 也运行在GMT+00:00，再由业务层显式转时区
最稳妥的解法：JVM 启动加 -Duser.timezone=GMT+00:00，并确保所有环境一致
这不是“绕开问题”，而是对齐事实：Oracle DATE 和 TIMESTAMP 本质是无时区的数值，JDBC 把它当成“本地时间”来解析，所以只要 JVM 时区和 DBTIMEZONE 一致，就不会平白多出偏移。
- 加参数：
-Duser.timezone=GMT+00:00（注意不是UTC，部分老版本驱动对UTC解析不稳定） - Docker 部署时，在
ENTRYPOINT或java命令里显式带上该参数，别依赖基础镜像的/etc/timezone - 测试时用
new Date()打印当前时间，确认输出的时区缩写是GMT而非CST或GMT+08 - 如果已有大量
SimpleDateFormat代码依赖本地时区，加完参数后要同步检查格式化逻辑是否仍符合预期
用 ResultSet.getTimestamp(int, Calendar) 可临时绕过，但别当长期方案
这个重载方法允许你传入一个带时区的 Calendar，JDBC 会按该日历解释时间值。比如传 Calendar.getInstance(TimeZone.getTimeZone("GMT+00:00"))，就能拿到和数据库存储一致的毫秒值。
- 示例：
rs.getTimestamp(1, Calendar.getInstance(TimeZone.getTimeZone("GMT+00:00"))) - 问题在于：每处
getTimestamp都得手动传，容易漏、难维护、和 ORM（如 MyBatis）不兼容 - MyBatis 中若用了
jdbcType="TIMESTAMP"，底层仍走默认getTimestamp(int)，不会自动用你配的Calendar - 只适合紧急修复单点问题，不能替代 JVM 时区对齐
真正麻烦的不是加个参数，而是团队里有人改了数据库时区、有人改了容器时区、还有人以为加了 Jackson 配置就万事大吉——最后查一圈发现三处时区全不一样。
