跨时区 Go 项目必须统一使用 UTC：时间戳、编译信息、日志、API 返回均用 time.Now().UTC()；面向用户再显式转换；Docker 不设 TZ；BuildTime 注入需 -u；GORM 连接加 loc=UTC；ParseInLocation 避免误解析。
跨时区团队用 Go 开发，必须把时间戳格式和编译信息统一到 UTC，否则本地开发、CI 构建、K8s Pod 日志三处时间对不上——不是“可能出错”，而是“必然漂移八小时”。
time.Now() 默认行为在不同环境里根本不可信
本地机器跑 time.Now() 可能返回 +0800 CST，Docker 容器里（尤其 Alpine）默认是 +0000（即 UTC），但不显式写 UTC，只写 +0000，容易误判为“没时区”。Kubernetes Pod 里更不可控——time.Local 依赖宿主机配置，而多数云厂商节点默认 UTC。
- 所有日志、审计时间、API 返回字段，一律用
time.Now().UTC()获取基准时间点 - 面向用户展示时再显式转换：
shanghai, _ := time.LoadLocation("Asia/Shanghai"); t.In(shanghai) - 别在 Dockerfile 里写
ENV TZ=Asia/Shanghai—— Go 的time包不读这个变量，Alpine 镜像甚至没装tzdata，time.LoadLocation("Asia/Shanghai")会直接返回nil
编译时注入 BuildTime 必须是 UTC 字符串
如果用 time.Now().Format("2006-01-02 15:04:05") 注入，本地构建是 2026-07-22 23:54:00，CI 流水线却变成 2026-07-22 15:54:00（UTC 时间），版本信息就失去可追溯性。
- 注入前先转 UTC：
$(date -u '+%Y-%m-%d %H:%M:%S')（Linux/macOS）或powershell -Command "Get-Date -UFormat '%Y-%m-%d %H:%M:%S'"（Windows） -
go build命令中写成：-ldflags "-X 'main.BuildTime=$(date -u '+%Y-%m-%d %H:%M:%S')'"，单引号必须包裹整个-X参数 - 变量声明必须为空：
var BuildTime string，不能是var BuildTime = ""或const，否则-X静默失效
GORM 写入数据库前必须强制转 UTC
MySQL 的 DATETIME 字段无时区语义，TIMESTAMP 字段虽默认按连接时区转换，但 GORM 不自动处理——它直接把 time.Time 值塞进去，结果取决于 MySQL server 的 time_zone 设置和连接参数，极易不一致。
立即学习“go语言免费学习笔记（深入）”；
- 全局设置 GORM 连接参数：
parseTime=true&loc=UTC，确保从 DB 读出的时间被解析为 UTC - 写入前手动转：
t.UTC()，而不是靠 ORM 自动转换 - 字段类型建议用
int64存 Unix 时间戳（t.Unix()），彻底规避时区解析歧义
ParseInLocation 解析字符串时最容易踩的坑
输入字符串是 "2026-07-22 10:00:00"（无时区标识），你却用 time.Parse("2006-01-02 15:04:05", s)，结果在 UTC 容器里被当成 10:00 UTC，再转上海时区变成 18:00，比预期晚了八小时。
- 无时区字符串（如 MySQL
DATETIME输出）必须用time.ParseInLocation(layout, s, loc)，loc是业务约定的时区（如time.LoadLocation("Asia/Shanghai")） - 带时区字符串（如
"2026-07-22T10:00:00+08:00"）用time.Parse(time.RFC3339, s)，它能正确识别并保留偏移 - 永远不要
time.Parse(...).In(loc)—— 先按Local解析再转，等于把上海时间当 UTC 解析一遍，逻辑错误
真正难的不是写对某一行代码，而是让 Makefile、CI 脚本、Dockerfile、本地开发终端全部用同一套 UTC 时间生成逻辑，且每个 time.LoadLocation 都检查 err —— 毕竟 "Asia/Shanghai" 写成 "CST" 或 "China/Beijing"，加载失败后继续执行，时间就全乱了。
