Go中time.Format输出UTC时间是因为time.Time值本身携带时区信息，Format仅按其内部Location渲染；若该Time由Parse（默认UTC）或网络API获取，则格式化结果为UTC而非本地时间。
Go 中 time.Format 为什么总输出 UTC 时间？
默认情况下，time.Now() 返回的是本地时区的 time.Time 值，但如果你直接调用 Format 而没显式设置时区，它会按该时间值自带的时区打印——而很多初学者从 Parse 或网络 API 拿到的时间默认是 UTC，导致格式化结果和预期不符。
关键点在于：time.Time 是带时区信息的值类型，格式化不改变其内部时区，只按它当前关联的 location 渲染。
- 用
time.Now().In(loc)切换时区再格式化，而不是靠字符串替换 -
time.Parse解析字符串时，默认使用time.UTC，除非你传入了明确的loc参数 - 常见错误：写
t.Format("2006-01-02")前没确认t.Location()是不是你想要的时区
如何安全地把字符串解析成指定时区的 time.Time？
Go 的 time.Parse 不自动识别时区缩写（如 “CST”、“PDT”），也不支持 ISO 8601 中带偏移的格式（如 2024-05-20T14:30:00+08:00）直接解析为本地时区——它会按字面量匹配预定义的时区名或偏移量。
推荐做法是优先使用带完整时区偏移的格式解析，再手动切换到目标时区：
立即学习“go语言免费学习笔记（深入）”；
- 对带偏移的字符串（如
"2024-05-20T14:30:00+08:00"），用time.RFC3339解析，它能正确提取偏移并生成对应时区的Time - 对只有日期时间没有偏移的字符串（如
"2024-05-20 14:30:00"），先用time.ParseInLocation指定目标时区，避免误入 UTC - 别依赖
LoadLocation("Asia/Shanghai")返回 nil 错误却不检查——它在某些容器环境（如 Alpine 镜像）下会失败，建议提前验证或 fallback 到time.FixedZone
time.LoadLocation 在 Docker 容器里为什么总是失败？
time.LoadLocation("Asia/Shanghai") 依赖系统时区数据库（通常是 /usr/share/zoneinfo），而精简镜像（如 golang:alpine）默认不包含这些文件，调用后返回 nil, error，但错误信息常被忽略，导致后续 In() panic 或静默出错。
解决方式不是硬编码偏移，而是确保运行时有可用的 zoneinfo：
- 用
golang:slim或golang:bookworm替代alpine镜像（它们自带 tzdata） - 如果必须用 alpine，在 Dockerfile 中加
apk add --no-cache tzdata并设置ENV TZ=Asia/Shanghai - 作为兜底，可构造固定偏移时区：
time.FixedZone("CST", 8*60*60)，但它不处理夏令时，仅适用于简单场景
跨时区比较时间时，为什么 After / Before 结果不对？
两个不同 Location 的 time.Time 值可以直接用 After、Before 比较，Go 内部会统一转为 Unix 时间戳（UTC 纳秒数）再比——这点没问题。真正容易出错的是「以为两个时间在同一时区」而做减法或格式化对比。
- 不要用
t1.Format(...) == t2.Format(...)判断是否相等，应直接用t1.Equal(t2) - 日志中打印时间前，明确用
t.In(time.Local).Format(...)或t.In(loc).Format(...)，避免混淆“显示值”和“真实时刻” - 数据库读写时注意 driver 行为：pq/pgx 默认把
timestamp with time zone当作 UTC 存，但timestamp without time zone无时区信息，需业务层约定解释方式
时区不是字符串标签，而是时间值不可分割的一部分；任何绕过 Location 直接操作字符串的转换，迟早会在夏令时切换或跨区域服务中露出破绽。
