微服务间时间同步必须统一使用time.UTC作为唯一可信源，所有时间操作需显式转UTC，数据库连接、Go运行时、API序列化均需严格配置，禁止依赖本地时区或模糊时区名。
微服务间时间同步不是靠“对齐时区”，而是靠统一时间锚点——所有服务必须用 time.UTC 作为唯一可信源，否则跨服务日志、定时任务、事件排序都会错乱。
数据库写入前没转 UTC，导致各服务读到的时间不一致
常见现象：Service A 写入 2024-05-20T10:00:00+08:00，Service B 读出来变成 2024-05-20T02:00:00Z，差 8 小时。
- 根本原因不是 ORM 或数据库配置，而是 Service A 的
time.Now()没调.UTC()就直接入库 - MySQL 连接字符串必须带
parseTime=true&loc=UTC；PostgreSQL DSN 加timezone=utc - Go 启动时强制设
time.Local = time.UTC（仅限单例服务，且要在 goroutine 启动前） - 别依赖
time.LoadLocation("UTC")，直接用内置常量time.UTC
API 接口返回时间字段带本地偏移，前端解析出错
错误示例："created_at": "2024-05-20T10:00:00+08:00" —— 这个 +08:00 是谁的本地？后端没声明上下文，前端不敢信。
- 删掉所有含
,time_rfc3339的 struct tag，让标准MarshalJSON生效（它默认输出Z结尾） - 真要返回带偏移的时间（如展示给用户），必须显式用
t.In(shanghaiLoc).Format(time.RFC3339)，且文档写明该字段对应Asia/Shanghai - 禁止用
t.Format("2006-01-02T15:04:05")这种无时区格式，它会套上time.Local，而容器里time.Local很可能是 UTC
用户时区动态切换时，time.LoadLocation 返回 nil 不报错
现象：传入 "CST" 或 "GMT+8"，time.LoadLocation 返回 nil，后续 t.In(loc) panic。
立即学习“go语言免费学习笔记（深入）”；
-
time.LoadLocation只认 IANA 时区名，例如"Asia/Shanghai"✅，"China/Beijing"❌（IANA 不存在） - 必须检查 error：
loc, err := time.LoadLocation(user.Timezone); if err != nil { /* fallback to UTC */ } - 缓存
*time.Location实例，别每次请求都重新LoadLocation（开销大，且可能触发系统时区文件读取失败） - 测试时用
timedatectl list-timezones | grep Shanghai确认系统支持的名称
最易被忽略的是“业务时间点”的构造——比如“今天 0 点”，不能用 time.Now().Truncate(24*time.Hour)，它依赖运行环境时区；必须基于用户时区构造：userLoc 下的 time.Date(year, month, day, 0, 0, 0, 0, userLoc)。
