Go time.Time 保存到 JSON 后时区信息为什么变化

在 Go 服务里把 time.Time 放进 JSON 后，最容易看到的现象是：保存前显示为 Asia/Shanghai 或 CST，取出来却变成 Local、固定偏移，甚至显示成 UTC。先给结论：大多数情况下变的是时区的“表示信息”，不是时间瞬时点。time.Time.MarshalJSON 写入的是带偏移的 RFC3339 字符串，序列化不会保留原来的 Location 名称和完整夏令时规则。

先把“时区变了”拆成三个可观察字段

一次排查不要只打印 t.String()。它把日期、偏移、缩写和 Location 混在一行里，容易把格式变化误判成数据损坏。应该分别观察 Unix 纳秒、Zone() 返回的偏移，以及 Location() 的名称。

例如同一个瞬时点可以显示为北京时间 20:00，也可以显示为 UTC 12:00。小时数不同并不代表时间错了；只有 Equal 判断失败，或偏移量与业务契约不符，才需要继续查输入和解析逻辑。

MarshalJSON 保存的是 RFC3339 表示，不是完整 Location

标准库文档规定，MarshalJSON 输出带引号的 RFC3339 时间字符串并包含亚秒精度；UnmarshalJSON 要求输入也是这种字符串。它能表达日期、时钟和数值偏移，例如 2026-09-08T20:00:00+08:00，却没有字段专门存放 Asia/Shanghai 这个地点名。

因此，反序列化后 Go 可以准确知道“相对 UTC 差 8 小时”，但不必知道这个偏移来自哪个 IANA 地点。对于没有夏令时的固定偏移场景，这通常足够；需要按历史或未来规则换算时，仅有偏移就不够了。

package main

import (
    "encoding/json"
    "fmt"
    "time"
)

func main() {
    loc, err := time.LoadLocation("Asia/Shanghai")
    if err != nil { // 时区数据库不可用时立即暴露配置问题。
        panic(err)
    }
    original := time.Date(2026, time.September, 8, 20, 0, 0, 0, loc)

    data, err := json.Marshal(original)
    if err != nil { // JSON 编码失败不能被静默忽略。
        panic(err)
    }
    var restored time.Time
    if err := json.Unmarshal(data, &restored); err != nil { // 输入必须符合 RFC3339。
        panic(err)
    }

    name1, offset1 := original.Zone()
    name2, offset2 := restored.Zone()
    fmt.Printf("json=%s\n", data)
    fmt.Printf("same_instant=%v, before=%s/%d, after=%s/%d\n",
        original.Equal(restored), name1, offset1, name2, offset2)
}

这段代码的关键不是某台机器打印出的缩写，而是 same_instant 应为 true，偏移量仍应是 28800。恢复后的 Location 名称可能因本机 Local 设置和解析路径不同而变化，这正是“时区信息”需要拆开讨论的原因。

接口边界先统一 UTC，展示边界再转换地点

如果字段表示一个跨服务传递的事件时刻，建议在接口契约中统一使用 UTC RFC3339，例如 2026-09-08T12:00:00Z。这样日志、消息和数据库中的文本不会依赖部署机器的本地时区。若业务确实需要保留用户输入的地点，例如预约规则或门店营业时间，则把地点名作为独立字段保存，不要指望单个 time.Time 的 JSON 自动携带它。

如果目标是前端显示，先解析传输值，再把它转换到用户或门店的地点：

func displayAt(value string, locationName string) (string, error) {
    parsed, err := time.Parse(time.RFC3339, value)
    if err != nil { // 先拒绝不带明确偏移的时间文本。
        return "", err
    }
    loc, err := time.LoadLocation(locationName)
    if err != nil { // 地点名来自配置时也必须检查加载错误。
        return "", err
    }
    return parsed.In(loc).Format("2006-01-02 15:04:05 MST"), nil
}

In 只改变解释时间的 Location，不改变瞬时点。这个动作应放在展示或业务计算边界，而不是收到 JSON 后无条件把所有值改成服务器 Local。

解析、比较和测试时最容易踩的四个坑

第一，只有日期和时分却调用 time.Parse 时，没有时区信息的输入会按 UTC 解释；如果这段文字本来代表上海时间，应使用 ParseInLocation，或在协议层补全偏移。第二，不要用 t1 == t2 判断两个时间是否是同一个瞬时点，== 还会比较 Location 和可能存在的单调时钟读数，优先使用 t1.Equal(t2)。

第三，序列化会去掉只在当前进程有意义的 monotonic clock 读数，所以把 time.Now() 放进 JSON 后再拿回来，不能期待内部计时信息仍在。第四，如果业务要重建夏令时规则，必须额外保存 IANA 地点名，例如把时间和 location: "America/New_York" 作为两个字段，由应用在目标日期重新计算。

相关问题

JSON 里的 Z 和 +08:00 哪个更好？

两者都能表达瞬时点。跨服务协议通常统一 UTC 的 Z，便于比较和排序；面向用户的接口也可以保留明确偏移，但要固定契约。

为什么重新格式化后显示成 UTC？

常见原因是输入没有时区，time.Parse 按 UTC 解释，或代码主动调用了 UTC()。检查原始字符串是否带 Z 或数值偏移，再确认解析方法。

想保留 Asia/Shanghai 应该怎么做？

单独保存地点名，并在展示时用 time.LoadLocation 加载后调用 In；不要把偏移量当作地点身份。

归根结底，Go time.Time 保存到 JSON 后的变化通常发生在 Location 名称和规则层。先用 Equal 确认瞬时点，再按接口、计算、展示三种边界分别约定 UTC、偏移和地点名，时区问题就不会再靠猜日志字符串解决。