Go 日志里的时间为什么总是 UTC：time.LoadLocation、容器时区和序列化边界

服务在开发机上打印的是北京时间，放进 Linux 容器后却变成了 UTC，排查日志时常常差 8 个小时。多数时候不是 Go 把时间算错了，而是程序加载的 *time.Location、容器里的时区数据和输出格式分别处在不同边界。

先看 Location，不要先改日志字符串

同一个时间点，用 UTC 和上海时区展示会得到两个不同的字符串，但它们指向的是完全相同的一刻。排查时先把 Location 和格式化结果一起打印出来：

now := time.Now()
fmt.Println("location:", now.Location())
fmt.Println("local:", now.Format(time.RFC3339))
fmt.Println("shanghai:", now.In(time.FixedZone("CST", 8*60*60)).Format(time.RFC3339))

如果容器里 time.Local 是 UTC，而业务又直接调用 time.Now().Format，日志自然会显示 +00:00。这不代表时间点错了，代表展示位置没有按业务约定设置。

time.LoadLocation 在容器里为什么会失败

time.LoadLocation("Asia/Shanghai") 会读取系统内置的时区数据库。精简镜像可能没有安装这份数据，调用后会得到类似 unknown time zone Asia/Shanghai 的错误。不要把错误丢掉，否则程序会在不同环境里悄悄出现两套时间规则。

func loadBusinessLocation() (*time.Location, error) {
    location, err := time.LoadLocation("Asia/Shanghai")
    if err != nil {
        return nil, fmt.Errorf("load business location: %w", err)
    }
    return location, nil
}

镜像由团队统一维护时，可以把时区数据作为运行环境的一部分内置进去；如果应用需要更稳定地携带规则，也可以评估 time/tzdata 的打包方式。两种方案都要用构建产物做一次真实启动检查，不要只在开发机上验证就上线。

日志、数据库和接口应该各自遵守什么规则

我更建议把“保存时间点”和“展示时间”分开约定：数据库存 UTC 时间点，服务间的 JSON 保留明确偏移，面向运维的日志按团队约定输出。这样换机器或跨地区部署时，数据仍然能正常比对校验。

不要用 strings.Replace 把 Z 改成 +08:00。那只是改了文字表面，没有改变原来的时间点；需要展示成本地时间时，应使用 t.In(location) 后再格式化。

JSON 序列化前，先决定谁负责转换

下面的结构体保存一个带位置的时间。只要调用方理解 RFC3339 规范，接口就能传递明确的偏移信息。

type Event struct {
    Name  string    `json:"name"`
    At    time.Time `json:"at"`
}

func eventJSON(location *time.Location) ([]byte, error) {
    event := Event{
        Name: "config-reloaded",
        At:   time.Now().In(location),
    }
    return json.Marshal(event)
}

如果接口规范要求统一 UTC，就在组装响应前调用 event.At.UTC()；如果产品页面必须展示用户所在地区的时间，就把时间点交给前端和用户时区处理。最怕的是接口返回 UTC，日志返回本地时间，排查文档却没有写清楚差异。

把容器时区问题变成可回归的检查

部署前可以用一个小检查确认三件事：目标镜像能加载 Asia/Shanghai，格式化结果包含预期偏移，JSON 反序列化后仍表示同一个时间点。

func TestBusinessTime(t *testing.T) {
    location, err := time.LoadLocation("Asia/Shanghai")
    if err != nil {
        t.Fatal(err)
    }

    source := time.Date(2026, 7, 26, 9, 30, 0, 0, time.UTC)
    local := source.In(location)
    if got := local.Format(time.RFC3339); got != "2026-07-26T17:30:00+08:00" {
        t.Fatalf("unexpected local time: %s", got)
    }
}

测试通过后，再在和生产完全一致的镜像里启动一次。这里别急着只改 Dockerfile 的环境变量，应用是否显式加载位置、日志采集器是否带时间戳，都可能改变最终看到的结果。

常见误区

UTC 时间是不是比北京时间少了 8 小时？

不是。UTC 和北京时间表示同一个时间点时，只是展示偏移不同；只有把字符串当成本地时间再次解析，才会真正引入偏差。

设置 TZ 环境变量后，Go 一定会使用它吗？

不能只靠假设。程序启动时打印 time.Local 并检查关键位置，才能确认镜像、运行时和日志采集链实际采用了什么规则。

固定使用 time.FixedZone 可以替代 LoadLocation 吗？

固定偏移适合明确不涉及夏令时的简单场景，但它不包含地区时区规则。涉及真实地区日期规则时，优先使用 IANA 时区名称。

相关问题

数据库应该保存本地时间还是 UTC？

跨地区系统通常保存 UTC 时间点，展示层再转换；单地区系统也要保持统一，否则未来迁移和对账会更麻烦。

日志时间和接口时间必须一样吗？

不必一样，但必须有明确约定。日志服务可以按团队时区展示，接口则保持 RFC3339 偏移，关键是排查文档要同时说明两者。

怎么快速确认容器里有没有时区数据？

直接运行应用级的 time.LoadLocation 检查比查看某个发行版目录更可靠，因为它验证的是 Go 程序真正使用的加载路径。

小结

Go 日志出现 UTC，先看 Location，再看容器时区数据，最后核对 JSON 和采集器边界。把时间点、展示位置和格式化责任分开，配合一次真实镜像启动检查，通常就能把“差 8 小时”的问题从线上偶发故障变成可测试的配置差异。