time.now() 高频调用慢因系统调用开销，vdso 优化后仍有跳转与寄存器操作；缓存毫秒级时间戳可降90%+开销，但需接受1ms误差；替代方案 runtime.nanotime() 非稳定api，慎用；真正瓶颈常在数据结构分配与序列化。
Go time.Now() 在高频打点时为什么慢？
因为每次调用 time.Now() 都会触发系统调用（如 clock_gettime(CLOCK_REALTIME, ...)），在 Linux 上虽经 vDSO 优化，但仍有函数跳转、寄存器保存/恢复等开销；当每秒打点数超 10 万次，这部分时间可能占到总耗时 15%–30%。
- 不是 GC 问题，也不是内存分配问题——
time.Now()返回的是栈上值，不逃逸 - 真实瓶颈在内核态/用户态边界切换 + 时间源读取逻辑（尤其在虚拟化环境或老内核中更明显）
- 如果你用
log.Printf("[%.3f] event", time.Since(start).Seconds())这类带格式化的写法，格式化本身开销往往比time.Now()还大
用 time.Now().UnixNano() 还是缓存时间戳？
直接缓存一个全局时间戳（比如每毫秒更新一次）能砍掉 90%+ 的时间调用开销，但必须明确接受「最多 1ms 误差」的语义妥协。适用于监控埋点、指标聚合、日志批次打点等场景，不适用于需要严格单调/精确顺序的事务时间戳。
- 推荐方式：启动一个 goroutine，用
time.NewTicker(1 * time.Millisecond)定期更新原子变量atomic.StoreInt64(&nowNs, time.Now().UnixNano()) - 读取时用
atomic.LoadInt64(&nowNs)，零分配、无锁、纳秒级响应 - 避免用
sync.Mutex包裹time.Now()—— 锁竞争反而更慢 - 注意：Windows 上 vDSO 不生效，缓存收益更大；macOS 的
mach_absolute_time本身较快，收益略低但依然可观
替代方案：runtime.nanotime() 能不能用？
可以，但要小心——runtime.nanotime() 是 Go 运行时内部函数，返回自启动以来的纳秒数（类似 monotonic clock），不提供绝对时间，且未暴露为公开 API。从 Go 1.18 起可通过 unsafe + 函数指针调用，但属非稳定行为，升级 Go 版本可能失效。
- 仅建议在极致性能敏感、可接受维护成本的内部组件中临时使用
- 正确姿势是配合一个启动时的
baseTime := time.Now()，后续用baseTime.Add(time.Duration(runtime.nanotime() - baseNano))换算（需自行处理溢出） - 切勿用于日志时间、HTTP 响应头
Date、JWTexp等依赖 wall clock 的地方 - Go 1.22 已将
runtime.nanotime()封装进time.Now().UnixMonotonic，但该字段只在 Go 1.22+ 可读，兼容性差
打点数据结构设计影响远大于时间获取本身
很多团队花精力优化 time.Now()，却忽略更重的损耗点：频繁构造 map[string]interface{}、JSON 序列化、或往 channel 发送结构体。一次打点若触发 2 次小对象分配，GC 压力可能比时间调用高一个数量级。
立即学习“go语言免费学习笔记（深入）”；
- 预分配打点结构体，用
sync.Pool复用（例如type Span struct { Ts int64; Name string; Tags [8]string }） - 避免在 hot path 上调用
json.Marshal()；改用预生成 key-value 字符串，或二进制协议（如 Protocol Buffers）批量编码 - 如果只是写入本地 ring buffer 或通过 UDP 发送，用
fmt.Appendf(buf, "%d|%s|%s", ts, name, tags)比构建结构体快 3–5 倍 - 确认你的 trace agent 是否已开启采样——全量上报时，网络和序列化才是真正的瓶颈，优化时间获取只是隔靴搔痒
事情说清了就结束。真正卡住高频率打点的，从来不是“要不要用 time.Now()”，而是你有没有把时间戳塞进一个分配少、拷贝少、序列化少的数据管道里。
