sync/atomic比mutex更适合高并发计数器，因其基于cpu原子指令实现无锁操作，避免goroutine阻塞唤醒开销；而mutex在争用激烈时性能断崖下降，且易引发semacquire等调度瓶颈。
为什么 sync/atomic 比 mutex 更适合高并发计数器
因为计数器本质是单个整型变量的读写，sync/atomic 直接操作 CPU 原子指令（如 XADD、LOCK XCHG），无锁、无调度开销；而 mutex 会触发 goroutine 阻塞/唤醒，一旦争用激烈，性能断崖式下降。
常见错误现象：用 mutex 包裹一个 counter++，QPS 上千后 runtime.mcall 占用飙升，pprof 显示大量时间花在 semacquire 上。
- 适用场景：HTTP 请求计数、限流桶令牌更新、连接池活跃数统计等「只读+自增/自减」高频操作
- 不适用场景：需要条件判断后才修改（如「若小于阈值才加一」），这时得用
CompareAndSwap或退回到mutex -
int32和int64必须对齐（即地址能被 4 或 8 整除），否则在 ARM 或 32 位系统上 panic："panic: unaligned 64-bit atomic operation"
atomic.AddInt64 的正确初始化和内存序要求
Go 的 atomic 操作默认提供 sequentially consistent 内存序，足够应对绝大多数计数器场景，但代价是可能插入不必要的内存屏障。不需要强一致时，可考虑 atomic.LoadInt64 + atomic.StoreInt64 组合，但计数器几乎不用这么干。
最容易踩的坑是未初始化就直接原子读——Go 允许，但值为 0；更危险的是用 var counter int64 然后传地址给 atomic 函数，这没问题；但若放在 struct 里且字段非首字段，要小心对齐问题。
立即学习“go语言免费学习笔记（深入）”；
- 必须用指针：
atomic.AddInt64(&counter, 1)，不是atomic.AddInt64(counter, 1) - 不能对局部变量取地址后跨 goroutine 使用（比如在 handler 里声明
var c int64，然后 go func(){ atomic.AddInt64(&c,1) }() —— 这是数据竞争） - 推荐初始化方式：
var reqCount int64（包级变量），或new(int64)分配，避免栈逃逸不确定性
Web handler 中怎么安全暴露原子计数器的当前值
直接 atomic.LoadInt64(&reqCount) 返回即可，无需加锁。但注意：HTTP 响应体里拼接字符串时别用 fmt.Sprintf("%d", atomic.LoadInt64(&reqCount)) —— fmt 是重量级包，会拖慢吞吐。简单场景用 strconv.AppendInt 更轻量。
错误示例：在 handler 里先 atomic.LoadInt64，再做逻辑判断，再 atomic.AddInt64 —— 这中间有竞态窗口，已不是原子“读-改-写”了。
- 暴露指标建议走 Prometheus：
promhttp.Handler()+prometheus.NewCounterVec，底层其实也用atomic，但封装了 label 和 metric 生命周期 - 如果只是调试打日志，用
log.Printf("count=%d", atomic.LoadInt64(&reqCount))安全，但别在每请求里打，会 IO 瓶颈 - 避免在
http.HandlerFunc闭包里捕获计数器变量地址，容易意外逃逸到堆上，增加 GC 压力
和 sync.Map 混用时的典型误用
sync.Map 本身不是为计数器设计的，它的 LoadOrStore、Store 不是原子整型操作。有人试图用 sync.Map 存 key→*int64，再对指针做 atomic 操作——这反而引入额外指针跳转和内存分配，得不偿失。
真正需要 per-key 计数（比如按路径统计 /api/user、/api/order），应该用 sync.Map 存 map[string]*int64，但每个 *int64 仍需独立初始化并用 atomic 操作，而不是对 sync.Map 本身做原子增。
- 错误写法：
m.LoadOrStore("/api/user", &int64(0)); atomic.AddInt64(m.Load("/api/user").(*int64), 1)——LoadOrStore返回的是 interface{}，类型断言失败会 panic - 正确做法：先确保 key 存在且值是 *int64，或统一用
sync.Once初始化每个 key 对应的计数器指针 - 更简单方案：直接用
map[string]int64+sync.RWMutex，QPS 不到万级时，读多写少下RWMutex性能足够，代码还更直白
原子操作本身很薄，但嵌入 Web 服务后，对齐、逃逸、内存序、组合使用这些点稍不注意，就会从“省事”变成“埋雷”。尤其是 struct 字段顺序和 int64 对齐，线上跑几天才复现的 panic，最不好查。
