goland数据库工具默认不继承系统时区，jdbc解析时间字段需显式配置servertimezone=asia/shanghai（mysql）、timezone=asia/shanghai（postgresql/新版sql server），否则显示时间与服务端不一致。
GoLand 数据库工具默认忽略时区配置
GoLand 的数据库客户端（Database Tool）本身不读取 TZ 环境变量，也不自动继承宿主机或容器的时区设置。它用的是 JVM 自带的时区逻辑，而 JVM 默认又常 fallback 到 UTC —— 所以你在 GoLand 里执行 SELECT NOW()，看到的时间很可能比服务器实际时间少 8 小时（比如 MySQL 服务端配了 Asia/Shanghai，但 GoLand 显示 2026-08-18 11:22:00）。
这不是连接失败，而是显示层错位：SQL 查询结果里的 DATETIME 字段被 JDBC 驱动按 JVM 本地时区解析了，和数据库真实存储值语义不一致。
- 检查当前 JDBC 解析时区：在 GoLand 的数据库控制台运行
SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP)，若返回+08:00说明服务端确实是上海时区，但 GoLand 显示值没对齐 - 不要依赖
SET time_zone='+08:00'临时会话设置——它只影响服务端计算，不改变 JDBC 对已有字段的解析行为 - 关键不是“让 GoLand 变成上海时间”，而是“让它按服务端真实时区解析时间字段”
MySQL 连接字符串中必须加 serverTimezone=Asia/Shanghai
GoLand 使用 JDBC 驱动连接 MySQL，默认不传 serverTimezone 参数时，驱动会尝试从服务端获取时区，但经常失败或 fallback 到 GMT。正确做法是在数据源 URL 末尾显式声明：
jdbc:mysql://localhost:3306/mydb?serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
注意三点：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
serverTimezone值必须是 IANA 时区名，CST、GMT+8、China/Beijing全部无效，会报Unknown system variable 'serverTimezone'或静默 fallback - 如果服务端 MySQL 配置了
default-time-zone='+08:00'，仍需传该参数——JDBC 不会自动读取这个配置 - 该参数只影响时间类型字段（
TIMESTAMP/DATETIME）的解析，不影响INT或BIGINT时间戳字段
PostgreSQL 和 SQL Server 没有 serverTimezone 参数
PostgreSQL 的 JDBC 驱动靠 timezone 参数控制，SQL Server 靠 sendStringParametersAsUnicode 和底层协议协商，二者都不认 serverTimezone：
- PostgreSQL 数据源 URL 示例：
jdbc:postgresql://localhost:5432/mydb?timezone=Asia/Shanghai - SQL Server 示例：
jdbc:sqlserver://localhost:1433;databaseName=mydb;encrypt=false;trustServerCertificate=true;timezone=Asia/Shanghai（注意：SQL Server JDBC 10.2+ 才支持timezone参数） - 若用旧版 SQL Server 驱动（如 6.x），
timezone不生效，只能靠服务端统一设为UTC，再在应用层转换
验证是否生效：连上后执行 SHOW timezone（PostgreSQL）或 SELECT SYSDATETIMEOFFSET()（SQL Server），看返回值是否含 +08。
GoLand 控制台里的时间显示仍可能不准
即使连接参数全对，GoLand 的查询结果表格里时间列仍可能显示为本地时间（比如你 Mac 系统设了上海时区，它就按上海显示；但 Linux 服务器上跑的 GoLand 可能显示 UTC）。这是因为 IDE 把 JDBC 返回的 java.time.LocalDateTime 再次做了本地化格式化。
- 最稳的验证方式：右键结果表 →
Copy as JSON，看原始值是否带时区偏移（如"2026-08-18T19:22:00+08:00"） - 若 JSON 里没偏移，说明 JDBC 层解析已出错，回头检查
serverTimezone或驱动版本 - 别信表格预览列的格式化时间，它只是 IDE 的 UI 层处理，和实际数据无关
真正要盯住的，是 JDBC 驱动拿到的原始 Timestamp 对象有没有被正确归一到服务端时区——这决定了你在 Go 代码里用 sqlx.StructScan 或 GORM 读出来的时间值是否可信。
