time.Now() 在高并发下完全线程安全，底层调用系统单调时钟，无锁且开销仅20–50 ns；纳秒精度易引发JSON溢出和时钟回拨误判，应优先使用.After()/.Sub()比较时间；批量场景可局部缓存time.Time实例以平衡精度与性能。
time.Now() 在高并发下是否线程安全
完全安全，time.Now() 是 Go 运行时内置的原子操作，底层调用系统单调时钟（如 CLOCK_MONOTONIC），不依赖共享状态，无需加锁。即使每秒百万次调用，也不会出现竞态或性能瓶颈。
常见误解是“并发多 goroutine 调用 time.Now() 会变慢或不准”，实际它在大多数 Linux 系统上开销约 20–50 ns，比一次函数调用还轻量。真正影响精度的不是并发本身，而是调用时机和后续处理方式。
纳秒级时间戳获取与截断陷阱
Go 默认提供纳秒级精度：time.Now().UnixNano() 返回自 epoch 起的纳秒数。但直接用于日志、ID 或存储时，容易踩两个坑：
- 纳秒值过大（如
1730010569123456789）导致 JSON 序列化溢出 int64（某些解析器会报错） - 不同 goroutine 在极短时间内（
解决方法不是“避免并发调用”，而是按需截断或补充：
立即学习“go语言免费学习笔记（深入）”；
- 存数据库或传前端：用
time.Now().UnixMilli()（Go 1.17+）——毫秒级足够，数值更小，兼容性好 - 需要唯一性：在纳秒基础上拼接 goroutine ID 或原子计数器，例如
atomic.AddUint64(&counter, 1) - 避免手动除法截断：别写
t.UnixNano() / 1e6，用现成的t.UnixMilli()或t.UnixMicro()，语义清晰且无整数溢出风险
时区与 monotonic clock 的隐式干扰
time.Now() 返回的 time.Time 包含两部分：wall clock（墙上时间）和 monotonic clock（单调时钟）。后者用于计算持续时间（如 t.Sub(prev)），前者用于显示或转换（如 t.Unix()）。
问题在于：当系统时间被 NTP 调整或手动修改时，wall clock 可能回拨或跳跃，但 monotonic clock 始终向前。如果你混用两者做判断，会出错：
- 错误写法：
if t1.Unix() > t2.Unix() { ... }—— 若期间发生时钟回拨，t1实际晚于t2，但 Unix 秒数反而更小 - 正确做法：比较时间点用
t1.After(t2)或t1.Sub(t2) > 0，它们自动使用 monotonic 部分，不受系统时钟扰动影响
尤其在监控、限流、超时控制等场景，必须用 .After() / .Before() / .Sub()，而不是拆解成 Unix() 数值比较。
批量时间戳生成时的缓存权衡
在高频日志、指标打点等场景，每条记录都调用 time.Now() 会产生可观开销（哪怕只有几十纳秒，百万次就是几十毫秒）。这时可考虑缓存，但要注意边界：
- 缓存当前时间到局部变量（如循环内一次
now := time.Now()）适用于单次批量处理，语义明确 - 用全局变量缓存并定期刷新（如每 10ms 更新一次）适合对精度要求不严的聚合统计，但会掩盖事件真实发生顺序
- 绝对不要用
time.Now().UTC()后再缓存——.UTC()是复制操作，不改变底层 monotonic 行为；真正要缓存的是time.Time实例本身
一个典型折中：在 HTTP 中间件里记录请求开始时间，用 ctx.Value 存入 time.Time，后续所有子逻辑复用它，既避免重复调用，又保证整个请求生命周期内时间基准一致。
真正难的不是“怎么拿到高精度时间”，而是“在并发、时钟漂移、存储限制、语义一致性之间做取舍”。多数业务根本不需要纳秒，但一旦用了，就得理解它附带的所有契约。
