time.Time 单调时钟字段在序列化前的处理

如果一个 time.Time 只在当前 Go 进程里计算耗时，可以让它保留 time.Now() 带来的单调时钟读数；如果它要进入 JSON、文本、消息或数据库，建议在边界前显式写成 t.Round(0)，并在恢复后用 Equal 比较。这样做不是为了“修复”序列化，而是把进程私有的测量信息和可交换的时间值分开。

记住一句话：单调时钟适合当前进程测时长，墙上时钟适合表达日期和跨边界传输；序列化前用 Round(0) 表达这个意图，恢复后不要依赖单调字段。

先把 time.Time 看成两种时钟读数

操作系统通常同时提供墙上时钟和单调时钟。墙上时钟可能因为校时发生跳变，适合回答“现在是哪一天”；单调时钟只用于持续测量，适合回答“这段操作经过了多久”。Go 没有把两套概念拆成两个公开类型，而是允许 time.Now() 返回的值同时携带它们。

因此，两个都带单调读数的时间值进行 Sub、Before、After、Equal 或 Compare 时，会优先使用单调读数；只要其中一个值没有单调读数，就退回到墙上时钟。这个规则正好解释了为什么进程内测耗时可靠，也解释了为什么序列化之后比较语义会变化。

start := time.Now()

// 当前进程内用 Since 计算耗时，优先利用单调时钟读数。
elapsed := time.Since(start)
if elapsed 

序列化前为什么常用 Round(0)

单调读数只对当前进程有意义，不能被另一个进程、另一台机器或下一次启动的程序解释。Go 官方文档明确说明，JSON、文本、二进制和 Gob 等序列化形式不会保存这个读数；反序列化构造出的 time.Time 也不含单调读数。

既然编码器本身会丢弃单调字段，为什么还要写 Round(0)？因为它能把“我要把这个值交给外部边界”的意图写在代码里，并且让进入结构体、日志或缓存前的值先回到只含墙上时钟语义的状态。Round(0) 不会把时间舍入到零点，它的特殊用途是清除单调读数。

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

func encodeEvent(name string, at time.Time) ([]byte, error) {
	// 清除只在本进程有意义的单调读数，再把墙上时钟写入 JSON。
	event := Event{Name: name, At: at.Round(0)}
	payload, err := json.Marshal(event)
	if err != nil {
		// 把编码错误交给调用方，避免发送半截消息。
		return nil, err
	}
	return payload, nil
}

这里的重点不是为了让 JSON 字符串变得不同，而是让数据模型明确：At 是一个可交换的时间点，而不是当前进程的计时器快照。对要写入数据库的字段，也可以在写入前采用同样的处理。

JSON、文本和数据库字段应该保存什么

跨边界字段通常只需要可还原的日期时间、时区偏移或 Unix 时间。不要尝试从 String() 输出里的 m=... 文本反推单调读数；那个调试显示不能作为协议字段。也不要把 time.Time 的内部布局当作稳定序列化格式。

反序列化后怎么比较

恢复后的时间通常没有单调读数。如果另一侧的值仍来自 time.Now()，两者比较会按墙上时钟进行，这正是跨边界比较所需要的语义。业务代码应该使用 Equal 判断同一时间点，而不是使用 ==。

func sameEventTime(payload []byte, expected time.Time) (bool, error) {
	var event Event
	if err := json.Unmarshal(payload, &event); err != nil {
		// 反序列化失败时返回错误，不能把零值当成有效时间。
		return false, err
	}

	// Equal 能正确处理 Location 不同或只有一侧带单调读数的情况。
	return event.At.Equal(expected), nil
}

== 为什么容易让 time.Time 比较失真

== 比较的不只是时间点，还会比较 Location 和单调读数。因此，即使两个值打印出来的日期时间相同，只要一个值来自 time.Now()、另一个值来自 JSON，或者两者关联的 Location 不同，== 也可能返回 false。

如果确实需要把时间作为 map key 或结构体的一部分做严格相等判断，先统一 Location，并用 Round(0) 清除单调读数，再决定是否使用 ==。但一般业务判断只关心时间点，直接使用 Equal 更符合意图。

一份可以直接套用的边界规则

1. 计时器、超时和耗时统计留在进程内，起止值都尽量来自 time.Now()。
2. 准备发送或持久化时，对要离开进程的值调用 Round(0)。
3. 协议字段明确时区或统一使用 UTC，不把本地 Location 名称当作跨服务契约。
4. 恢复后的时间用 Equal、Before、After 比较，不用 == 代替业务语义。
5. 需要计算“真正经过的现实时间”时，注意有些系统休眠期间单调时钟可能停止；这时按业务需要清除单调读数后再比较。

常见问题

Round(0) 会把时间改成当天零点吗？

不会。它的特殊行为是清除单调时钟读数，墙上时钟表示的时间点仍然保留。

JSON 反序列化后还能使用单调时钟吗？

不能。单调读数不会被 JSON 保存，反序列化得到的值只能按墙上时钟语义参与比较。

什么时候可以用 ==？

只有在你已经明确统一 Location、清除了单调读数，并且确实需要比较完整值表示时才考虑。多数业务代码使用 Equal 更稳妥。

参考资料：Go 官方 time 包文档 https://pkg.go.dev/time；Go 官方 time 源码说明 https://go.dev/src/time/time.go。