应使用 atomic.AddUint64 进行成功率统计，因其轻量、无锁、避免 mutex 瓶颈与 channel 阻塞；读取时须用 atomic.LoadUint64 保证可见性，并防御除零和溢出风险。
为什么不用 mutex 或 channel 做成功率统计
用 sync.Mutex 包裹计数器更新，每请求一次加锁/解锁，在 QPS 过万时会明显成为瓶颈；用 channel 把事件发给 collector goroutine，看似解耦，但高并发下 channel write 会阻塞或丢数据，且额外分配内存。成功率统计本质是两个整型变量的原子增减（总请求数、成功请求数），完全没必要引入重量级同步机制。
atomic.AddUint64 是唯一需要的写操作
成功率 = 成功数 / 总数，两者都用 uint64 类型，所有写入只调用 atomic.AddUint64(&counter, 1)：
- 入口处对总请求数原子加 1
- 响应写回前（如 HTTP status == 2xx）对成功数原子加 1
- 避免在 defer 或 recover 中更新——失败路径可能不走那里，导致漏计
- 不要用
atomic.SwapUint64或CompareAndSwap，它们没意义，纯增加不需要条件判断
读取成功率时必须用 LoadUint64
暴露指标端点（如 /debug/stats）时，直接读值即可，但必须用 atomic.LoadUint64：
- 普通赋值
total = totalCounter不保证可见性，其他 goroutine 可能看到陈旧值 - 不要把
LoadUint64放在中间件里高频调用——哪怕只是读，频繁访问同一缓存行也会引发 false sharing - 计算成功率时先读成功数，再读总数，顺序无所谓，因为成功率本身不要求强一致性（允许毫秒级偏差）
- 示例：
success := float64(atomic.LoadUint64(&successCounter)) / float64(atomic.LoadUint64(&totalCounter))
注意 uint64 溢出和除零风险
uint64 溢出不是崩溃，而是回绕成 0，但会导致成功率突变为 NaN 或 0/0 → Inf。实际中极少发生（需 2⁶⁴ 次请求），但除零必须防御：
- 总数为 0 时，成功率应返回 0.0 或 -1，不能直接除
- 不要用 float64 转换后再做除法来“规避”，该转还是得转，重点是加判断
- 如果服务生命周期很长且 QPS 极高，可考虑定期归档并重置计数器（用
atomic.SwapUint64），但绝大多数场景无需
真正容易被忽略的是：成功率指标本身没有时间维度，它只是当前累计值的比值；若要观察“最近一分钟成功率”，就得换成滑动窗口，那 atomic 就不够用了——这时候该上 ring buffer 或分桶计数，而不是硬撑。
