在并发编程里，计数器是个很常见的需求。但实现起来，坑也不少。先说核心结论：Go 1.19 及以上版本，优先上 sync.AtomicInt64。它底层走的 CPU 原子指令，无锁、高性能、语义清晰，死锁风险基本为零。Go 1.18 及更早版本，就得手动封装 atomic.AddInt64 和 LoadInt64 了，或者干脆升级 Go 版本。如果直接用 int64 自增，那非原子操作在并发下必然丢数据，这是个硬伤。
计数器必须用 sync.AtomicInt64 还是 sync.Mutex？
高并发场景下，直接用 int64 自增，数据会丢得你心疼。用 sync.Mutex 也能行，但锁的开销摆在那里。Go 1.19 以上，推荐优先用 sync.AtomicInt64，无锁的 CPU 原子指令，性能好、语义清晰，而且不会死锁。至于 Go 1.18 及之前版本，没有现成的 sync.AtomicInt64，得手动封装 atomic.AddInt64 等函数，或者考虑升级 Go 版本。
常见错误现象：counter++ 在 goroutine 中并发执行后，结果远小于预期。比如启了 100 个 goroutine 各加 100 次，最终只到 2000 多——这就是典型的竞态未防护。
- 读写操作必须统一走
atomic.LoadInt64和atomic.AddInt64，千万别混着普通变量赋值，否则还是会有竞态问题。 - 避免在原子操作中间插入非原子逻辑，比如先
Load再判断再Add，这已经不是原子“比较并交换”了。 - 如果确实需要 CAS 行为，比如“仅当当前值为 X 时才加 1”，直接用
atomic.CompareAndSwapInt64。
如何支持重置、带标签的多维计数（比如按 HTTP 方法 + 状态码统计）？
当单个计数器不够用，需要按不同维度统计时，比如按 HTTP 方法和状态码计数，就别硬套全局变量了。推荐用 map 配合读写锁。但要注意，map 本身不是线程安全的，即使加了锁，也必须保护所有操作入口，不能有遗漏。
更稳妥的做法是用 sync.Map，它适合读多写少的场景，或者自己封装一个带锁的结构体。如果维度固定，比如只有 method 和 status，那用嵌套 map 配合 sync.RWMutex 会更易调试，内存也更紧凑。
示例场景：记录 GET 200、POST 500 的调用次数：
type StatusCounter struct {
mu sync.RWMutex
m map[string]map[int64]int64 // method → status → count
}
func (c *StatusCounter) Inc(method string, status int64) {
c.mu.Lock()
if c.m == nil {
c.m = make(map[string]map[int64]int64)
}
if c.m[method] == nil {
c.m[method] = make(map[int64]int64)
}
c.m[method][status]++
c.mu.Unlock()
}
- 初始化
c.m必须在Lock内，否则并发写 nil map 会 panic。 - 如果只是追加计数，不频繁查全量，可以用
sync.Map减少锁粒度，但它的Range不保证一致性，遍历时可能漏项。 - 标签过多时，比如加了 path 和 user_id，要注意 cardinality 爆炸，这时候该上 Prometheus 或专用指标后端了。
计数器怎么暴露给 Prometheus？
直接暴露 sync.AtomicInt64 的值给 Prometheus 是不行的，需要适配成 prometheus.Counter 或 Gauge 类型。最省事的办法是用 prometheus.NewGaugeFunc 包一层：
var reqTotal = &atomic.Int64{}
reqCounter := prometheus.NewGaugeFunc(prometheus.GaugeOpts{
Name: "http_requests_total",
Help: "Total number of HTTP requests.",
}, func() float64 {
return float64(reqTotal.Load())
})
prometheus.MustRegister(reqCounter)
注意，Counter 类型要求单调递增，而 GaugeFunc 可以任意变化，所以适合带重置的计数器。如果业务需要 reset，就别用 prometheus.Counter 了，因为它不支持减操作。
- 注册前确保
reqTotal已初始化，虽然atomic.Int64默认零值安全，但习惯上还是显式Store(0)一下。 - 不要在
GaugeFunc回调里做耗时操作，比如查 DB 或 HTTP 请求，否则会阻塞 Prometheus 抓取。 - 如果需要同时暴露多个指标，比如 success 和 error 分开，建议拆成多个
GaugeFunc，别挤在一个回调里计算。
为什么本地测试没问题，压测时计数器增长变慢甚至卡住？
典型原因往往是误用了粗粒度锁，比如整个计数器结构共用一把 sync.Mutex，导致高并发下 goroutine 大量阻塞排队。另一个隐蔽问题是缓存行伪共享：多个 atomic.Int64 实例紧挨着定义，被 CPU 放进同一个 cache line，频繁修改会引发 core 间的缓存同步风暴。
怎么验证？用 go tool trace 看看 goroutine 阻塞在 mutex 上的时间，或者用 perf stat -e cache-misses 观察缓存失效率是否异常高。
- 每个计数器字段之间至少填充 64 字节，也就是 cache line 的宽度，比如
count atomic.Int64; _ [64]byte。 - 避免把多个高频更新的计数器塞进同一个结构体，尤其不要和大字段如
[]byte混排。 - 压测时观察 GC Pause 时间，如果计数器对象频繁新建，比如每次请求 new 一个 Counter，会导致 GC 压力飙升，间接拖慢计数逻辑。
真正难调的，从来不是怎么写出来，而是怎么让它在 10k QPS 下还准、还快、还不悄悄吃掉一半 CPU。这些细节，不打日志、不跑压测，根本看不到。