优先用 sync.AtomicInt64（Go 1.19+），因其底层为无锁 CPU 原子指令，性能高、语义清晰、无死锁风险；Go 1.18 及之前需手动封装 atomic.AddInt64/LoadInt64；直接用 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 方法 + 状态码统计）？
单个计数器不够用时，别硬套全局变量。推荐用 map + 读写锁，但要注意：不能直接对 map 加 sync.RWMutex 后并发读写 —— map 本身非线程安全，即使加锁也得保护所有操作入口。
立即学习“go语言免费学习笔记（深入）”；
更稳妥的做法是用 sync.Map（适用于读多写少）或封装一个带锁的结构体。若维度固定（如 method/status），优先用嵌套 map 配 sync.RWMutex，比 sync.Map 更易调试、内存更紧凑。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
示例场景：记录 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内，否则可能 panic（并发写 nil map） - 如果只是追加计数、不频繁查全量，
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已初始化，否则Load()可能 panic（虽 atomic.Int64 默认零值安全，但习惯上显式reqTotal.Store(0)） - 不要在
GaugeFunc回调里做耗时操作（如查 DB、HTTP 请求），否则会阻塞 Prometheus 抓取 - 若需同时暴露多个指标（如 success/error 分开），建议拆成多个
GaugeFunc，别挤在一个回调里计算
为什么本地测试没问题，压测时计数器增长变慢甚至卡住？
典型原因是误用了粗粒度锁（比如整个计数器结构共用一把 sync.Mutex），导致高并发下 goroutine 大量阻塞排队。另一个隐蔽问题是缓存行伪共享（false sharing）：多个 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”。这些细节不打日志、不跑压测根本看不到。
