Go 使用 MySQL 驱动插入时间戳时，默认将 time.Time 值转为 UTC 发送给数据库，而驱动默认时区为 time.UTC，导致本地时区（如 UTC+3）的时间被错误减去偏移量存储，引发显示偏差。解决关键是显式配置驱动时区或统一使用 UTC 存储。
go 使用 mysql 驱动插入时间戳时，默认将 `time.time` 值转为 utc 发送给数据库，而驱动默认时区为 `time.utc`，导致本地时区（如 utc+3）的时间被错误减去偏移量存储，引发显示偏差。解决关键是显式配置驱动时区或统一使用 utc 存储。
在 Go 应用中连接 MySQL 时，time.Now().Local() 生成的带本地时区（如 Asia/Istanbul, UTC+3）的时间值，并不会原样写入数据库。go-sql-driver/mysql 在序列化 time.Time 时会先调用 .In(time.UTC) 进行转换（源码参考），再以 YYYY-MM-DD HH:MM:SS 格式发送——这意味着：若你传入 2016-11-07 22:51:02 +0300 EET，驱动会将其转为 2016-11-07 19:51:02 UTC 后发送；而 MySQL 若未显式设置时区或字段类型为 TIMESTAMP（自动按服务器时区解释），就可能按自身系统时区（UTC+3）反向解析该字符串，最终存为 2016-11-07 19:51:02（即比本地时间早 3 小时），造成肉眼可见的“变晚”现象。
✅ 推荐解决方案（生产环境首选）：统一使用 UTC 存储
这是最健壮、可扩展性最强的做法：
- 所有
time.Time值在入库前统一转为 UTC：app_log.CreatedDate = time.Now().UTC() // ✅ 强制转为 UTC
- 数据库连接 DSN 中不指定
loc参数（保持默认UTC），确保行为一致； - 查询时仍获取
time.Time类型值，前端或业务层按需转为本地时区展示：// 查询后转本地显示（如 Web 响应） localTime := dbTime.In(time.Local) // 自动适配服务器本地时区
⚠️ 备选方案（仅限兼容旧逻辑）：显式配置驱动时区
若必须让驱动按本地时区解析时间（不推荐），需在 DSN 中添加 loc 参数，并确保其值能被 Go 正确解析：
// 示例：DSN 中加入 loc=Local（需 URL 编码） dsn := "user:pass@tcp(127.0.0.1:3306)/dbname?parseTime=true&loc=Local" // 或更精确地指定时区名（推荐）： dsn := "user:pass@tcp(127.0.0.1:3306)/dbname?parseTime=true&loc=Europe%2FIstanbul"
? 注意：
loc=Local依赖 Go 运行时读取系统时区（/etc/localtime），在容器化或跨平台部署中易出错；务必配合parseTime=true启用时间解析。
? 关键配置检查清单：
- ✅ MySQL 服务端时区应设为
+00:00（UTC）：SET GLOBAL time_zone = '+00:00'; - ✅ 表字段优先使用
TIMESTAMP（自动时区转换）而非DATETIME（无时区语义）； - ✅ Go 代码中避免混用
.Local()和.UTC()，全程统一时区上下文； - ✅ 开启
parseTime=true（否则time.Time被当作字符串处理，失去时区能力）。
遵循 UTC 存储原则，不仅能彻底规避驱动时区陷阱，还能简化分布式系统中的时间比对、定时任务、日志归档等场景——时间永远是一个可靠、无歧义的标尺。
