time.now() 时间戳突降说明系统时钟被回拨，应优先使用单调时钟（如time.since、sub）计算间隔，绝对时间场景需自行实现防回拨缓存并配合ntp slewing配置。
time.Now() 返回的时间戳突降，说明系统时钟被回拨了
Go 的 time.Now() 直接读取操作系统时钟，一旦系统时间被手动调整或 NTP 服务校正导致倒退，time.Now().UnixNano() 就可能比前一次调用还小。这在依赖单调递增时间戳的场景（如分布式 ID、缓存过期判断、日志排序）里会直接引发逻辑错误——比如生成重复 ID、缓存提前失效、事件乱序。
根本原因不是 Go 有问题，而是它不干预系统时钟行为。你不能靠重写 time.Now 来解决，得换思路。
- 优先使用单调时钟（monotonic clock），它不受系统时钟回拨影响，但只适合测间隔，不能转成绝对时间
- 若必须用绝对时间戳（比如存数据库、对外暴露），就得自己做“防回拨”兜底
- Linux 上可启用
CLOCK_MONOTONIC，但 Go 标准库的time.Now()不走这个；runtime.nanotime()走的是它，但返回值无意义，仅用于差值计算
用 time.Now().Sub() 做差值而非 time.Now().UnixNano() 做绝对比较
很多 bug 出在拿两个 time.Now().UnixNano() 直接相减或比较大小。只要中间发生回拨，结果就不可信。正确做法是：用 time.Time 对象本身做减法，Go 内部会自动使用单调时钟基线算出真实经过时间。
例如判断某操作是否超时，别这么写：
立即学习“go语言免费学习笔记（深入）”；
// ❌ 错误：依赖绝对时间戳大小关系
start := time.Now().UnixNano()
// ... do work
if time.Now().UnixNano() - start > 5e9 {
log.Println("timeout")
}
而应该：
// ✅ 正确：用 Time 对象减法，底层用单调时钟
start := time.Now()
// ... do work
if time.Since(start) > 5*time.Second {
log.Println("timeout")
}
-
time.Since()、t1.Sub(t2)、time.Until()都安全，它们不依赖系统时钟绝对值 - 但
t.UnixNano()、t.Format()、time.Parse()等涉及绝对时间的操作，仍会受回拨影响 - 如果你在循环里高频调用
time.Now()并做UnixNano()比较，几乎必踩坑
需要绝对时间戳时，加一层“防回拨缓存”
比如生成 Snowflake ID、记录日志时间字段、设置 Redis 过期时间，都要求时间戳不倒流。这时得自己维护一个“见过的最大时间戳”，每次取新时间前先和缓存比对。
最简实现（单 goroutine 安全）：
var lastTS int64
<p>func safeTimestamp() int64 {
now := time.Now().UnixMilli()
if now > lastTS {
lastTS = now
} else {
lastTS++
}
return lastTS
}
- 注意：这里用
UnixMilli()而非UnixNano()，避免整数溢出风险，且毫秒级精度对大多数业务已够用 - 并发场景下需加锁或用
atomic.CompareAndSwapInt64，否则多个 goroutine 同时写lastTS可能导致跳变或卡住 - 该方案会让时间戳略微“膨胀”，但保证单调性；如果回拨幅度大（比如跨天），连续自增可能造成明显偏差，需结合告警或降级策略
systemd-timesyncd 或 chrony 配置不当会加剧问题
很多生产环境没关掉 “step” 模式，NTP 同步时直接跳变系统时间，而不是缓慢 slewing。这是时钟回拨的主因之一。
- 检查
chronyd是否启用了makestep：运行chronyc tracking，看Leap status和System clock是否有跳变 - 推荐配置
makestep 1.0 -1（只在偏差 >1 秒时 step，否则 slewing）或彻底禁用makestep 0 -1 - Linux kernel 5.11+ 支持
CLOCK_MONOTONIC_RAW，更抗干扰，但 Go 未暴露该时钟源；如有强需求，得用 cgo 调用
真正麻烦的不是代码怎么写，而是你得同时管住内核、NTP 服务、Go 应用三层。任何一层松动，防回拨逻辑就可能被绕过。
