Go 使用 go-sql-driver/mysql 操作 MySQL 时，默认将 time.Time 值转为 UTC 后写入数据库，若未显式配置时区，会导致本地时间被错误转换，表现为入库时间比预期早（或晚）若干小时。
go 使用 `go-sql-driver/mysql` 操作 mysql 时，默认将 `time.time` 值转为 utc 后写入数据库，若未显式配置时区，会导致本地时间被错误转换，表现为入库时间比预期早（或晚）若干小时。
在 Go 应用中向 MySQL 写入时间戳时出现“时间变慢 3 小时”（如本地 22:51 入库后显示为 19:51），根本原因在于：MySQL 驱动默认以 time.UTC 解析和序列化 time.Time 值，而你的 CreatedDate = time.Now().Local() 返回的是本地时区（UTC+3）的时间对象。驱动在发送前会将其强制转换为 UTC 时间（即减去 3 小时），再交由 MySQL 存储——而 MySQL 表字段若为 TIMESTAMP 类型，又会按服务器时区（通常为系统时区或 SYSTEM）解释该值，最终导致双重时区偏移，结果失真。
✅ 正确做法是：统一使用 UTC 存储 + 显式声明驱动时区。推荐两种方案：
方案一：配置 DSN 指定时区（推荐）
在初始化数据库连接时，于 DSN 中添加 parseTime=true&loc=Local 参数（注意：loc=Local 表示使用 Go 进程的本地时区）：
import "database/sql"
import _ "github.com/go-sql-driver/mysql"
dsn := "user:password@tcp(127.0.0.1:3306)/dbname?parseTime=true&loc=Local"
db, err := sql.Open("mysql", dsn)
if err != nil {
log.Fatal(err)
}⚠️ 注意：loc=Local 并非字符串字面量 "Local"，而是 URL 编码后的 loc=Asia%2FShanghai 或 loc=Europe%2FIstanbul 更稳妥；若需动态设置，可用 url.QueryEscape(time.Local.String()) 生成（如 time.Local.String() 返回 "Europe/Istanbul"，则编码后为 "Europe%2FIstanbul"）。
方案二：全局统一使用 UTC（更健壮的工程实践）
// 写入时主动转为 UTC app_log.CreatedDate = time.Now().UTC() // DSN 中仍启用 parseTime，但无需指定 loc（默认 UTC 已符合预期） dsn := "user:pass@tcp(127.0.0.1:3306)/db?parseTime=true"
此时 MySQL 中存储的是标准 UTC 时间（如 2016-11-07 19:51:02），应用读取后可按需转换为任意时区展示：
t := row.TimeField // 从 DB 读出的 time.Time（已自动解析为 UTC） localTime := t.In(time.Local) // 转成本地时区显示 utcTime := t.UTC() // 或保持 UTC 用于计算
⚠️ 关键注意事项
-
parseTime=true是前提：否则time.Time字段会被当作[]byte返回，无法自动解析； - 避免混用
time.Local()和time.UTC()：同一服务中应严格约定存储时区（强烈建议全栈 UTC）； - MySQL 服务器时区不影响
TIMESTAMP存储逻辑（它始终转为 UTC 存储），但会影响NOW()、CURRENT_TIMESTAMP等函数返回值——可通过SELECT @@time_zone;查看，建议设为'+00:00'或'UTC'保持一致； - 若必须用
DATETIME类型（不自动时区转换），则需确保应用层与数据库时区完全对齐，复杂度更高，不推荐。
✅ 总结：问题不在代码逻辑或 MySQL 配置，而在驱动时区默认行为。通过 DSN 显式指定 loc 或坚持 UTC 存储，即可彻底解决时间偏差。长期来看，以 UTC 为唯一可信时间基准，展示层按需格式化，是分布式系统最可靠的时间处理范式。
