不能直接用 mutex 做请求计数，因为高并发下锁争用严重、性能差；应使用 atomic.adduint64 等原子操作实现无锁计数，并注意指针传参、缓存行对齐及 prometheus 集成规范。
为什么不能直接用 mutex 做请求计数
高并发场景下，sync.Mutex 会成为吞吐瓶颈：每次 Lock()/Unlock() 都涉及系统调用和调度器介入，尤其在每秒几十万次请求的统计场景中，锁争用会让 CPU 大量空转。atomic 提供无锁的底层指令（如 x86 的 XADD），把计数操作压到单条 CPU 指令完成，延迟从纳秒级降到皮秒级。
但要注意：atomic 只保障单个操作的原子性，不提供复合逻辑的原子保护（比如“先读再加再写”必须用 atomic.AddUint64 而不是 atomic.LoadUint64 + atomic.StoreUint64）。
正确使用 atomic.AddUint64 统计请求数
最常见错误是把计数器声明成普通变量后试图用 atomic 操作——必须用指针传入。Go 的 atomic 函数全部要求指针参数，否则编译报错：first argument to atomic operation must be addressable。
实操建议：
- 计数器定义为
var reqCount uint64（不能是局部变量或 struct 匿名字段） - 递增统一用
atomic.AddUint64(&reqCount, 1)，不要用++或+= - 读取用
atomic.LoadUint64(&reqCount)，避免直接读变量（可能拿到未刷新的寄存器缓存值） - 如果需要周期性归零（如每分钟统计），用
atomic.SwapUint64(&reqCount, 0)，它返回旧值且保证原子性
按状态/路径维度做分片计数时怎么避免 false sharing
多个 uint64 紧挨着定义（比如放在同一 struct 里）会导致 CPU 缓存行伪共享：一个核更新 count_200，会把整个 64 字节缓存行（含 count_404、count_500）标记为 invalid，其他核读写相邻字段被迫重新加载。
解决方法：
- 每个计数器单独声明，中间用
_ [12]uint64填充（x86 缓存行通常是 64 字节，uint64占 8 字节，12 个刚好占满） - 或者用
type Counter struct { v uint64; _ [12]uint64 }封装，确保每个实例独占缓存行 - 切忌用 map[string]uint64 存路径计数——map 本身非原子，且 key 查找有锁和内存分配开销
如何安全地把 atomic 计数暴露给 Prometheus
Prometheus 的 prometheus.GaugeOpts 不接受 *uint64，直接传 atomic.LoadUint64(&reqCount) 返回值会丢失实时性（采集瞬间的快照，后续变化不可见）。正确做法是实现 prometheus.Gauge 接口：
type atomicGauge struct {
ptr *uint64
}
func (g *atomicGauge) Set(v float64) { atomic.StoreUint64(g.ptr, uint64(v)) }
func (g *atomicGauge) Inc() { atomic.AddUint64(g.ptr, 1) }
func (g *atomicGauge) Dec() { atomic.AddUint64(g.ptr, ^uint64(0)) }
func (g *atomicGauge) Get() float64 { return float64(atomic.LoadUint64(g.ptr)) }
注册时传 &atomicGauge{ptr: &reqCount}。注意 Dec() 用 ^uint64(0) 实现减 1（因为 atomic.AddUint64 不支持负数），且所有方法都必须只调用 atomic 函数，不能混用普通赋值。
分片计数器聚合上报时，务必在 Get() 中遍历所有分片并 atomic.LoadUint64 求和——任何中间变量缓存都会导致统计滞后。
