atomic.LoadInt64读不到最新值一定是读写未配对：必须用atomic.StoreInt64写、atomic.LoadInt64读，混用普通读写会绕过内存屏障，破坏happens-before同步；同时需确保int64地址8字节对齐，否则可能panic。
atomic.LoadInt64 读不到最新值？一定是没配对用 Store
直接 fmt.Println(counter) 或 val := counter 去读一个被 atomic.StoreInt64(&counter, 100) 写过的变量，大概率看到旧值。这不是 bug，是绕过了内存屏障——普通读写不参与 Go 的 happens-before 同步机制。
必须严格配对：atomic.StoreInt64 写的值，只能靠 atomic.LoadInt64 读到最新；反之亦然。混用就等于放弃可见性保证。
- 错误示范：
atomic.StoreInt64(&x, 42)后用fmt.Println(x)读 - 正确做法：所有读写都走 atomic 函数，哪怕只是“看看值”
- 验证方式：加
-race运行，这类混用会被竞态检测器直接标出
为什么 int64 普通读写本身可能原子，却还要用 atomic.Load/Store？
在 64 位系统且地址 8 字节对齐时，*int64 的单次读或写确实是硬件原子的（不会读到“高低 32 位撕裂”）。但 atomic 的核心价值不在防撕裂，而在建立内存顺序。
没有 atomic，CPU 和编译器可能重排指令，导致其他 goroutine 看到“写 ready = 1”成功，却仍读到旧的 data 值。而 atomic.StoreInt64 插入释放屏障（release fence），atomic.LoadInt64 插入获取屏障（acquire fence），强制形成 happens-before 关系。
- 生产者：先写
data = 123，再atomic.StoreInt64(&ready, 1) - 消费者：先
atomic.LoadInt64(&ready) == 1成立，之后的atomic.LoadInt64(&data)才能确保看到 123 - 漏掉任意一个 atomic，整个同步链就断了
CompareAndSwap 失败不是错误，是并发常态
atomic.CompareAndSwapInt64(&x, old, new) 返回 false，只说明“你基于的 old 值已过期”，不是操作失败。它本质是“读→算→比→换”四步组合，中间任何一步被抢占，就会失败。
正确模式必须循环重试，不能只调一次：
for {
old := atomic.LoadInt64(&x)
if atomic.CompareAndSwapInt64(&x, old, old+1) {
break
}
// 高竞争下可加 runtime.Gosched()，但多数场景不需要
}
- 漏掉循环 → CAS 可能永远不生效，逻辑卡死
- 把
old提前算好再进循环 → 更糟，old 值从一开始就是错的 - CAS 不是设值工具，而是“条件更新”的同步原语，别当普通赋值用
结构体里放 int64 做原子字段，对齐不是可选项
在 ARM32、32 位 x86 或启用 -gcflags="-d=checkptr" 时，atomic.LoadUint64 对未对齐地址会 panic。Go 要求 uint64 地址必须是 8 字节对齐。
结构体字段顺序直接影响偏移量，unsafe.Offsetof(s.Count) % 8 必须为 0：
- 危险写法：
type Bad { Name string; Count uint64 }——Name长度不确定，Count可能不对齐 - 稳妥写法：
type Good { Count uint64; _ [0]byte }或把uint64放最前面 - 验证命令：
go run -gcflags="-d=checkptr" main.go，运行时立刻暴露对齐问题
指针类型原子操作（StorePointer/LoadPointer）同样要求存取时类型完全一致，且对象生命周期不能提前结束——这点容易被忽略，但一旦出错就是静默数据损坏。
