time.now() 默认返回本地时区时间，具体取决于系统 /etc/localtime 或 tz 环境变量；docker 容器中若未配置时区则退化为 utc，易引发跨环境时间漂移，业务中应统一使用 time.now().utc() 保证确定性。
time.Now() 返回的是什么时区的时间？
默认返回的是本地时区时间，具体取决于运行环境的 TZ 环境变量或系统 /etc/localtime 配置。在 Docker 容器里，绝大多数基础镜像（如 golang:alpine、golang:slim）默认没有设置时区，time.Now() 实际返回的是 UTC 时间（即 +0000），但不显式标注 UTC，只写 +0000 —— 这极易被误认为是“无时区”，其实它就是 UTC。
常见错误现象：time.Now().Format("2006-01-02 15:04:05") 在本地开发机显示 2026-07-01 09:27:00 +0800 CST，但在 Kubernetes Pod 里却输出 2026-07-01 01:27:00 +0000，日志时间“倒退”八小时，排查时才发现是时区漂移。
- 不要依赖
time.Now()的默认行为做业务逻辑，尤其在微服务间传递时间或存库前 - 统一用
time.Now().UTC()获取基准时间点，再按需转换 - 若必须用本地时区（如面向用户的展示层），显式加载：
loc, _ := time.LoadLocation("Asia/Shanghai")，再调用time.Now().In(loc) - Docker 构建时加一句
ENV TZ=Asia/Shanghai不解决根本问题——Go 的time包不读TZ环境变量做默认时区，它只影响initLocal()初始化系统时区文件，而 Alpine 镜像甚至没装 tzdata
解析带时区的时间字符串该用 Parse 还是 ParseInLocation？
看输入字符串是否自带时区偏移信息。如果字符串含 +0800、Z 或 UTC 等（如 "2026-07-01T09:27:00+08:00"），优先用 time.Parse；如果字符串纯本地时间、无时区标识（如 "2026-07-01 09:27:00"），必须用 time.ParseInLocation 并传入目标时区 *time.Location。
容易踩的坑：time.Parse("2006-01-02 15:04:05", "2026-07-01 09:27:00") 返回的时间值其 .Location() 是 time.Local，但这个 Local 是运行时的系统时区——在 UTC 容器里，它就变成 UTC，而非你期望的北京时间。
- 对 API 输入的 RFC3339 时间（如
"2026-07-01T09:27:00+08:00"）：直接time.Parse(time.RFC3339, s)，结果自带正确时区 - 对数据库查出的无时区时间字符串（如 MySQL
DATETIME字段）：必须用time.ParseInLocation(layout, s, loc)，loc应与该字段约定的业务时区一致（例如全站用上海时区，就固定用time.LoadLocation("Asia/Shanghai")） - 永远不要对无时区字符串用
time.Parse后再调.In(loc)—— 这会把本应属于上海时间的"09:27"先当成 UTC 解析成09:27 UTC，再转成上海时间变成17:27，错得离谱
微服务间传递时间，该传 time.Time 还是时间戳？
传时间戳（int64 秒或纳秒）更安全。gRPC 或 HTTP JSON 接口若直接序列化 time.Time，不同语言/SDK 对时区的处理不一致：Go 默认转 RFC3339 带偏移，Java Jackson 可能丢偏移，前端 JavaScript Date 构造时又按本地时区 reinterpret —— 最终各端看到的时间可能差好几小时。
性能与兼容性影响：时间戳是纯数字，序列化/反序列化零开销，无时区歧义，且便于 Elasticsearch、Prometheus 等系统直接消费。
- 对外提供 API 时，请求/响应体中时间字段统一定义为
int64（单位秒），文档注明 “Unix timestamp in UTC” - 内部服务通信（如 gRPC）可传
google.protobuf.Timestamp，它本质也是秒+纳秒字段，且 proto 生成代码自动转成各语言原生时间类型，比手写 JSON 更可靠 - 仅在单体或强信任域内（如同一 Go 微服务集群内部函数调用），才考虑直接传
time.Time，但仍建议所有time.Time值在创建时就明确绑定 UTC 时区：t := time.Now().UTC()
数据库存时间，为什么必须存 UTC？
因为数据库本身不存储时区元数据（MySQL DATETIME、PostgreSQL timestamp without time zone 都是“裸时间”），而微服务可能部署在多个时区的节点上。如果各服务用自己的本地时区写入，同一条记录在不同实例上读出来的时间语义完全不同。
典型错误：用户在北京提交订单，服务 A（北京时区）写入 "2026-07-01 09:27:00"；运维在新加坡查库，服务 B（新加坡时区）读出来自动 interpret 成 09:27 SGT，比实际晚一小时——这不是 bug，是设计缺陷。
- 写库前一律调
t.UTC()，哪怕原始时间来自time.Now().In(shanghaiLoc) - 读库后，按业务需要转换：面向用户的展示层用
t.In(shanghaiLoc)，后台调度任务仍用t.UTC()计算 - PostgreSQL 的
timestamp with time zone类型看似能存时区，但它实际存储的仍是 UTC 值，只是输入输出时做自动换算——本质上还是 UTC 存储，别被名字误导 - ORM 如 GORM 默认不处理时区，
db.Create(&order)时若order.CreatedAt是本地时间，就会直接存成本地值，务必提前归一化
最易被忽略的一点：日志打点里的 time.Now() 如果没强制 .UTC()，在跨时区排查链路时，各服务日志时间无法对齐——TraceID 下的耗时计算会失真。微服务里，时间不是“看起来对”，而是“绝对一致”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
