Go time.Time 序列化后为何失去单调部分

我第一次遇到这个现象，是把 time.Now() 放进 JSON 后再解码，发现调试输出里不再带原来那段单调读数。这个结果不是精度丢失，也不是 JSON 库改坏了 time.Time，而是 Go 有意把只能在当前进程解释的单调时钟排除在序列化格式之外。

因此，跨进程传递的时间点应当只依赖墙上时间，进程内测量耗时则应保留原始的 Time 或直接保存 Duration。下面按这个边界拆开看。

官方资料：https://pkg.go.dev/time

先分清 time.Time 里有哪两种时间

Go 的 time.Now() 返回的值可能同时包含 wall clock 和 monotonic clock。前者回答“现在是几点”，会受到校时影响；后者回答“两个时刻相隔多久”，只在创建它的进程内有意义。

Sub、Before、After、Equal 和 Compare 在两个值都带单调读数时，会优先使用单调读数。这个设计让本地耗时统计不容易被系统时间向前或向后调整干扰。

序列化为什么必然丢掉单调部分

单调读数是当前进程运行时钟的偏移量，换到另一个进程后没有可比较的共同起点。Go 官方文档因此明确规定：GobEncode、MarshalBinary、MarshalJSON 和 MarshalText 生成的序列化结果都会省略它；对应的解码方法也只会创建不含单调读数的时间。

这意味着序列化前后的两个值，日历时间可以相同，但内部携带的信息不再相同。可以把它理解成“传输了一个时间点”，而不是“把原进程的计时器搬到了新进程”。

比较时不要把 == 当成时间相等

time.Time 的 == 比较不只看时间点，还会比较 Location 和单调读数。一个值来自 time.Now()，另一个值来自 JSON 解码时，即使它们表示同一瞬间，== 也可能不是你想要的判断。

判断两个时间是否表示同一时刻，用 Equal；判断先后，用 Before、After 或 Compare。当比较双方有一方没有单调读数时，这些方法会回退到 wall clock。

package main

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

func main() {
    original := time.Now()

    // JSON 只承担跨边界传递时间点，不承担当前进程的计时状态。
    payload, err := json.Marshal(original)
    if err != nil {
        panic(err)
    }

    var restored time.Time
    // 解码后的 Time 没有原进程的 monotonic reading。
    if err := json.Unmarshal(payload, &restored); err != nil {
        panic(err)
    }

    fmt.Println("same instant:", original.Equal(restored))
    fmt.Println("same struct:", original == restored)
}

上面的重点不是某一次输出，而是判断语义：Equal 适合时间点比较，== 适合你明确控制了位置和内部表示的场景。若确实需要在进程内把值规范成不带单调读数的形式，可以使用 t = t.Round(0)，但它不会让跨进程时间重新获得单调能力。

把耗时与时间点分开存储

本地计时从未跨出当前进程时，直接保留起点：

start := time.Now()

// 这里放需要统计的工作；示例不假设具体业务耗时。
elapsed := time.Since(start)
fmt.Println(elapsed)

如果任务需要跨进程排队或写入数据库，不要把“开始时间序列化后，稍后再用它计算可靠耗时”当成同一只时钟。更稳妥的做法是同时记录两个字段：

• 事件时间：使用可传输的 time.Time，用于展示、排序和审计。
• 耗时预算或已耗时：使用 time.Duration，由产生它的进程计算后传递。

若只是想去掉当前值的单调部分再交给缓存或日志，也可以显式调用 t.Round(0)。这表达的是“我只要稳定的墙上时间表示”，而不是修复了序列化造成的丢失。

常见问题

序列化后时间会变得不准确吗？

它保留的是可序列化的墙上时间；丢掉的是只对当前进程有意义的单调读数。两者解决的问题不同。

为什么 time.Since 比 now.Sub(反序列化时间) 更适合本地耗时？

time.Since 使用从当前进程获得的起点；反序列化结果没有原来的单调读数，跨边界计算只能回退到墙上时间。

应该用 Unix 时间戳代替 time.Time 吗？

如果协议只需要表达时间点，Unix 时间戳可以更明确；如果还要处理时区、格式化和日期运算，继续使用 time.Time 也可以，关键是不要把它当作可跨进程携带的单调计时器。

总结一下：time.Time 序列化后失去单调部分是 Go 的边界设计。原始值留在当前进程时，用它做耗时和先后判断；进入 JSON、Gob、数据库或消息队列后，只把它当作时间点，并把真正的耗时单独保存为 Duration。