atomic.LoadInt64 读到 0 或旧值主因是变量未8字节对齐（尤其struct非首字段或局部变量），或混用裸读写；须确保int64首字段、全程用atomic接口、初始化也用atomic.StoreInt64。
直接用 atomic.AddInt64 和 atomic.LoadInt64 就能实现线程安全、无锁的负载统计，但必须确保变量地址对齐、类型匹配、不混用读写方式，否则可能 panic 或读到陈旧值。
为什么 atomic.LoadInt64 有时读到 0 或旧值
常见现象是：计数器明明被 atomic.AddInt64 多次更新，但 atomic.LoadInt64 却长期返回 0 或明显偏低的值。根本原因不是原子操作失效，而是变量未按 8 字节对齐（尤其嵌套在 struct 中时），或误用了局部变量地址。
- Go 运行时只保证全局变量、包级变量、或 struct 首字段天然对齐；中间字段不保证对齐，
int32或int64若前面有string或bool字段，极易错位 - 局部变量（如函数内
var counter int64）取地址传给 atomic 函数，行为未定义，某些平台会 panic - 验证方法：
unsafe.Alignof(counter)应等于 8；若在 struct 中，用unsafe.Offsetof(s.field)确认偏移是 8 的倍数
struct 中放计数器必须满足的三个条件
不能把 ReqCount int32 直接塞进 Stats 结构体然后传 &s.ReqCount 给 atomic.AddInt32——这会触发 panic 或未定义行为。
- 必须用
int64（非int32或int），因 64 位原子操作在所有平台都要求严格对齐，且int32在 struct 中更难保证对齐 - 必须放在 struct 的第一个字段，例如：
type Stats struct { ReqCount int64; OtherField string } - 若无法调整字段顺序，可加
//go:align64注释（Go 1.17+），但不如提为包级变量省心
读写必须全程走 atomic 接口，禁止裸读裸写
混用普通赋值和原子操作是高频出错点：比如用 counter = 0 替代 atomic.StoreInt64(&counter, 0)，会导致其他 goroutine 看不到更新；用 fmt.Println(counter) 直接读，可能拿到缓存中的陈旧值。
- 所有写操作统一走
atomic.StoreInt64或atomic.AddInt64 - 所有读操作统一走
atomic.LoadInt64，包括日志打点、指标暴露、调试打印 - 初始化也建议用
atomic.StoreInt64(&counter, 0)，而非裸赋值counter = 0 - 轮询类索引（如后端节点选择）推荐用
atomic.AddUint64，因uint64在所有平台天然对齐，且避免溢出翻转问题
浮点型指标（如平均耗时）不能直接 atomic 操作
sync/atomic 不支持 float64 原子操作。声明 var avgTime float64 后试图原子更新它，编译会失败或运行时报错。
- 可行方案一（推荐 Go 1.19+）：
atomic.StoreUint64(&bits, math.Float64bits(avgTime))，读取时用math.Float64frombits(atomic.LoadUint64(&bits)) - 可行方案二：改用
sync.RWMutex保护整个浮点变量，适用于更新不频繁、读多写少场景 - 切勿尝试用
unsafe强转指针绕过限制——行为未定义，不同架构表现不一致
真正容易被忽略的是：atomic 只解决单变量的原子性，不解决时间窗口聚合（如“过去 1 秒请求数”）或多维分桶（如按 status + path 统计）。这类需求一旦硬套 atomic，反而会引入更隐蔽的竞态或逻辑错误。
