业务超时应该使用墙上时间还是单调时间，如何避免系统校时影响

业务超时优先使用单调时间，日志和业务事件时间才使用墙上时间。Go 的 time.Now() 返回值可以同时带有墙上时钟读数和当前进程内的单调时钟读数；对两个仍保留单调读数的 Time 做 Sub、Since、Until、Before 或 After，Go 会优先按单调部分计算，从而不受系统校时直接影响。

官方地址：https://pkg.go.dev/time

一句话决策：进程内测“过了多久”用 time.Now 产生的值；跨进程传递“何时发生”用墙上时间或传剩余 Duration；不要序列化并依赖单调读数。

• 耗时、重试间隔、请求超时：优先保留单调语义。
• 日志、订单时间、审计字段：保存 UTC 或带时区的墙上时间。
• RPC deadline：传剩余时长更稳妥，传绝对时间时要考虑机器时钟偏差。

先把超时问题拆成两种“时间”

墙上时间回答“现在是哪一刻”，会被 NTP 校时、人工改时区或虚拟机时间同步调整。单调时间回答“从起点到现在经过了多久”，它不负责展示日期，也没有跨机器的含义。把两者混成一个 Unix 时间戳再相减，正是超时提前或延后的常见来源。

例如请求开始时保存 start := time.Now()，处理结束时使用 time.Since(start)。即使系统日期在中间被向前或向后校正，只要两个值都来自同一进程且仍带单调读数，间隔计算仍以单调时钟为主。这个结论适合进程内的超时、重试退避和性能统计。

用 Go API 写出不怕校时的进程内超时

最容易维护的写法是保留一个本地起点，或者直接为本地 deadline 保存 time.Time。不要先调用 UnixNano() 变成整数再计算，因为 Unix 值只表达墙上时间，并不携带单调读数。

func withinBudget(start time.Time, budget time.Duration) bool {
	// Since 会优先使用 start 与当前值共有的单调时钟读数。
	return time.Since(start) 

如果需要把 deadline 交给 context.WithDeadline，也应在本地进程中用 time.Now().Add(timeout) 建立它。context 的取消仍需要由调用方负责，单调语义只是让截止点的本地比较不依赖墙上时钟跳变。

跨进程时不要搬运单调读数

time.Time 的单调部分只在当前进程有意义。JSON、文本、二进制等序列化形式不会保存这段进程私有读数；time.Parse、time.Unix 和反序列化得到的时间也没有单调读数。因此下面两种协议设计要明确区分：

例如客户端还有 800 毫秒预算，可以传 timeout_ms: 800，服务端收到后立刻用自己的 time.Now().Add(800*time.Millisecond) 建立本地截止点。若传的是绝对时间，服务端还要面对网络延迟、两台机器时钟不一致和重试链路扣减预算等问题。

三个容易让语义失效的边界

第一，Round、Truncate、In、UTC 和 Local 会剥离单调读数；它们适合格式化或改变墙上时间解释，不宜把结果继续当作高可靠的测量起点。第二，== 比较的不只是时间瞬间，还可能比较 Location 和单调读数；判断两个时间是否代表同一时刻，应优先考虑 Equal。第三，部分系统在休眠期间可能暂停单调时钟，因此“机器睡眠了多久”与“进程运行期间经过多久”需要按产品语义选择，不能仅靠 API 名称猜测。

记录时间时可以同时保留两个字段：started_at 使用 UTC 墙上时间方便排查，elapsed 使用 time.Since(start) 方便指标统计。这样既能回答“事件发生在什么时候”，也能回答“处理耗时多久”。

按任务选择时间字段的清单

需要测量的对象先问“是否在同一个进程内”。如果答案是是，优先使用 time.Time 的单调语义；如果要跨进程，就传剩余 Duration 或可读的绝对墙上时间，并在接收端重新建立本地判断。只要将“显示时间”和“经过时间”分成两个字段，系统校时就不会悄悄改变业务超时结果。

相关问题

为什么格式化后再比较不可靠？格式化结果只保留墙上时间文本，丢失了进程内单调读数，而且字符串比较还受布局和时区影响。

RPC 应该传时间戳还是超时秒数？单次调用通常传剩余时长更容易扣除网络耗时；必须表达业务发生时刻时再传 UTC 时间戳，并在服务端设置时钟偏差容忍范围。

参考资料：https://pkg.go.dev/time（Go 标准库 time 包文档）。