time.now() 不适合高精度差值计算，因其返回墙钟时间，受 ntp 调整、手动校时等影响可能回跳或突变，导致微秒级差值为负或非单调；应使用 time.since() 或 t.sub(s) 等基于单调时钟的差值方法。
time.Now() 为什么不适合做高精度差值计算
time.Now() 返回的是系统墙钟（wall clock），受 NTP 调整、手动校时、闰秒插入等影响，可能回跳或突变。在微秒级计时场景（比如性能压测、事件延迟分析）中，连续两次 time.Now() 相减的结果可能为负，或出现非单调跳跃，导致统计失真。
实操建议：
- 避免用
time.Now().Sub(prev)计算单次耗时，尤其在循环内高频调用时 - 若必须用墙钟（如记录绝对时间戳），请配合
time.Since()，它内部仍调用time.Now()，但语义更清晰，不解决根本问题 - Linux 上可通过
adjtimex(2)查看当前时钟调整状态，验证是否处于频繁校正中
用 time.Now().UnixNano() 做微秒差值依然危险
time.Now().UnixNano() 看似“更精细”，但本质仍是墙钟采样，精度提升不等于可靠性提升。实际测试中，在开启 NTP 的服务器上，相邻两次调用差值偶尔出现 -1000~5000 纳秒的跳变，远超微秒级需求容忍范围。
常见错误现象：
- 压测中
latency := time.Now().UnixMicro() - startMicro得到负数 - 直方图里出现大量集中在 0 或极小值（如 1~2 μs）的异常尖峰，实为时钟回退伪影
- 同一段代码在不同机器上统计结果差异大，部分机器因 NTP 配置激进而抖动剧烈
正确做法：用 time.Now().Sub() + 单调时钟底层保障
Go 运行时从 1.9 开始在支持的系统（Linux/FreeBSD/macOS/Windows）上默认使用 CLOCK_MONOTONIC（或等价机制）实现 time.Now() 的底层采样——但仅限于差值计算逻辑。也就是说：time.Since()、t.Sub(s)、t.After(s) 等方法内部会自动切换到单调时钟路径，而 t.UnixNano() 仍走墙钟。
所以关键不是“不用 time.Now()”，而是“只用它的差值方法”：
- ✅ 正确：
start := time.Now(); ... ; elapsed := time.Since(start) - ✅ 正确：
start := time.Now(); ... ; elapsed := time.Now().Sub(start) - ❌ 错误：
start := time.Now().UnixMicro(); ... ; elapsed := time.Now().UnixMicro() - start - ⚠️ 注意：
elapsed是time.Duration，单位是纳秒；微秒级只需elapsed.Microseconds()或elapsed / time.Microsecond
极端场景下需显式控制：runtime.LockOSThread + VDSO 或 clock_gettime
当你的程序运行在容器中、被 cgroup 限频、或需要亚微秒级抖动控制（如高频交易 tick 捕获），Go 默认的单调时钟仍可能因调度延迟引入误差。此时需绕过 Go 运行时封装：
- Linux 下可借助
clock_gettime(CLOCK_MONOTONIC, ...)配合syscall.Syscall或golang.org/x/sys/unix直接调用，避开 Go 的 GC 停顿和 goroutine 切换开销 - 对延迟敏感路径，用
runtime.LockOSThread()绑定 OS 线程，再配合time.Now()差值，能将 P99 抖动从 ~20μs 降至 ~3μs（实测数据，取决于内核版本与 CPU 频率稳定性） - VDSO 启用状态可通过
cat /proc/self/maps | grep vdso确认；未启用时clock_gettime会触发系统调用，增加开销
真正难的不是获取一个高精度数字，而是让这个数字在多线程、多核、有调度、有时钟校正的环境中保持可比性——Go 的 time.Since 已覆盖绝大多数场景，但一旦你开始怀疑那几个微秒的偏差来源，就得往下挖到内核时钟源和 Go runtime 的线程绑定策略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
