必须确保变量地址对齐、类型匹配、不混用读写方式，否则因struct字段未对齐或裸读写导致panic或读到陈旧值；浮点型需转uint64处理，轮询索引推荐atomic.adduint64。
直接用 atomic.AddInt64 和 atomic.LoadInt64 就能实现线程安全、无锁的负载统计，但必须确保变量地址对齐、类型匹配、不混用读写方式。
为什么不能直接对 struct 字段做 atomic 操作
常见错误是把计数器定义在 struct 里，比如：type Stats struct { ReqCount int32 }，然后传 &s.ReqCount 给 atomic.AddInt32。这会触发 panic 或未定义行为——因为 int32 在 struct 中可能未按 4 字节对齐（尤其前后有其他字段时）。Go 运行时只保证全局变量、包级变量、或 struct 首字段天然对齐；中间字段不保证。
解决办法很简单：
- 把计数器提为包级变量（最省心）
- 若必须嵌套，用
int64且放在 struct 第一个字段（type Stats struct { ReqCount int64; OtherField string }） - Go 1.17+ 可加
//go:align64注释强制对齐，但非必需
atomic.AddInt64 和 atomic.LoadInt64 必须配对使用
不要混用普通赋值和原子读写。比如写 counter = 0 替代 atomic.StoreInt64(&counter, 0)，会导致其他 goroutine 看不到更新（缓存可见性问题）；同样，用 fmt.Println(counter) 直接读取而非 atomic.LoadInt64(&counter)，可能读到陈旧值。
正确做法：
- 所有写操作统一走
atomic.StoreInt64或atomic.AddInt64 - 所有读操作统一走
atomic.LoadInt64 - 初始化也建议用
atomic.StoreInt64(&counter, 0)，而非裸赋值
轮询索引类统计要用 atomic.AddUint64 配合取模
像负载均衡器中轮询选择后端节点，本质是维护一个递增索引：index % len(backends)。这时必须用 atomic.AddUint64(&b.index, 1)，不能用 int32——因为 uint64 在所有平台都天然对齐，且避免溢出后符号翻转问题。
注意点：
- 返回值是自增后的值，所以要减 1 再取模：
i := atomic.AddUint64(&b.index, 1) - 1 - 不要用
atomic.SwapUint64或CompareAndSwap做轮询，没必要且更慢 - 如果后端列表动态变化，原子索引只能保证“选得快”，不保证“选得准”；需额外加锁或用 CAS 配合版本号
浮点型指标（如平均响应时间）不能直接 atomic
sync/atomic 不支持 float64 原子操作。想统计平均耗时，常见错误是声明 var avgTime float64 然后试图原子更新它。
可行方案只有两个：
- 用
atomic.Uint64存储math.Float64bits(avgTime)，读取时再math.Float64frombits转回（Go 1.19+ 推荐） - 改用
sync.RWMutex保护整个浮点统计结构（适合低频更新、高频读取场景）
别尝试自己封装 CAS 循环更新 float——精度丢失、ABA 问题、性能反而更差。
真正难的不是调用哪个函数，而是判断「这个统计值是否真的需要每毫秒都精确」。很多场景下，用 atomic 做秒级聚合 + 定期刷到 Prometheus，比强求微秒级原子更新更实际、更稳定。
