Go time 怎样比较带单调时钟的时间间隔

如果要比较 Go 中两个 time.Time 的先后，直接使用 Before、After、Equal 或 Compare；如果要计算经过了多久，使用 Sub。由 time.Now() 得到的两个时间都带有当前进程可用的单调时钟读数时，Go 会优先用这部分读数做比较和相减，因此不容易受到系统校时影响。

官方文档：https://pkg.go.dev/time

先把四种比较写法分开

Before 和 After 适合写条件，Equal 表达两个值代表同一个时间点，Compare 适合需要统一返回 -1、0、1 的排序或分支。它们比较的是时间点，不是字符串显示结果，也不要求两个值使用同一个时区展示。

package main

import (
    "fmt"
    "time"
)

func compareDeadline(now, deadline time.Time) string {
    // 用 Before 判断是否还没到截止时间，避免比较格式化后的字符串。
    if now.Before(deadline) {
        return "未到截止时间"
    }
    // Equal 表达同一时刻；Compare 则适合需要数值结果的调用方。
    if now.Equal(deadline) {
        return "正好到期"
    }
    return fmt.Sprintf("已过期，排序结果=%d", now.Compare(deadline))
}

这个场景不要写成 now == deadline。== 不只比较时间点，还会比较 Location 和内部的单调时钟读数；即使两个值代表同一瞬间，也可能因为来源不同而得到 false。对业务语义来说，Equal 更准确。

测量间隔时让单调时钟接管

如果问题是“这段代码运行了多久”，不要读取两个格式化时间再相减。把开始时刻留在内存中，结束时调用 Sub，或者直接使用 Since：

func loadCost() time.Duration {
    start := time.Now()

    // 这里放实际工作，例如读取文件或等待一个内部任务。
    doWork()

    // time.Since 会沿用 start 携带的单调时钟语义计算耗时。
    return time.Since(start)
}

func doWork() {
    time.Sleep(20 * time.Millisecond)
}

time.Now 返回的值可能同时包含墙上时钟和单调时钟。若两个操作数都有单调读数，Before、After、Equal、Compare 和 Sub 会使用单调读数，忽略墙上时钟；这正适合进程内的耗时统计。单调读数只在当前进程内有意义，不能拿来当作可持久化的时间戳。

解析和序列化后为什么会换一种比较方式

从 time.Parse、time.Unix、JSON 解码或数据库取出的时间，通常没有当前进程的单调读数。调用 UTC、Local、In、Round 或 Truncate 也可能产生不带单调读数的新值。此时只要比较的一方没有单调读数，Go 就会回退到墙上时钟。

这并不意味着结果错误：墙上时钟才是跨进程、跨机器传输的时间语义。但要分清用途：

两个容易踩到的边界

第一，使用 Round(0) 可以明确剥离单调读数，例如要把时间作为稳定的业务值比较或保存时，可以写成 clean := t.Round(0)。这不会改变时间点本身，只会改变内部比较所能使用的附加信息。

第二，部分系统在机器休眠时会暂停单调时钟。官方文档提醒，这种情况下用单调读数计算的 Sub 可能不等于现实世界经过的时间。如果业务要统计跨休眠的真实间隔，就要明确采用墙上时钟，并接受系统校时带来的另一类影响。

相关问题

为什么 time.Time 不能优先用 ==？

因为 == 会把 Location 和单调读数也纳入比较。想判断两个值是否表示同一时刻，应使用 Equal。

time.Since 和 end.Sub(start) 有什么区别？

两者都用于计算间隔；Since(start) 直接取当前时间，适合测量函数耗时，end.Sub(start) 适合已经明确拿到结束时刻的代码。

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

不能依赖它。单调读数只服务于当前进程，编码和解码后通常只剩墙上时钟，因此跨进程数据应按时间点语义比较。