Go原子操作必须遵守三条铁律：变量地址稳定、类型精确匹配、所有访问全程走atomic函数；否则易panic或读旧值。
Go 里做原子操作，sync/atomic 是唯一标准路径，但直接套函数名就开干，八成会 panic 或读到旧值——根本原因不是不会用，而是没守住三条铁律：变量地址必须稳定、类型必须精确匹配、所有访问必须全程走 atomic 函数。
int64 字段在 struct 里 panic？检查 unsafe.Offsetof 是否 %8 == 0
在 ARM32、x86（32 位）或开启 -gcflags="-d=checkptr" 时，atomic.LoadInt64 对未对齐的 int64 地址会直接 panic。这不是 Go bug，是 CPU 硬件限制。
- 典型翻车结构体：
type Bad { hits uint32; total int64 }——total偏移为 4，未对齐 - 验证方式：
unsafe.Offsetof(bad.total) % 8 == 0必须为 true，否则别碰atomic - 修复方案优先级：把
int64字段挪到 struct 开头 > 前面补_ [4]byte> 用struct{ _ [8]byte; v int64 }包装 - 交叉编译务必测试目标平台：
GOARCH=386 go run main.go跑一遍，别只信本地 amd64
atomic.AddInt64 不是 counter++ 的替代品，它是唯一合法解
counter++ 在汇编层拆成“读→加1→写”三步，两个 goroutine 同时执行必然丢更新；而 atomic.AddInt64(&counter, 1) 编译为单条硬件原子指令（如 x86 的 LOCK XADD），不可分割。
- 必须用
int64类型变量，不能用int（32 位系统上int可能是 32 位） - 变量地址必须稳定：
var counter int64放包级作用域 ✅，函数内var x int64; atomic.AddInt64(&x, 1)❌（函数返回后地址失效） - 所有读写必须统一走 atomic：
fmt.Println(counter)或counter = 0会绕过内存屏障，读到陈旧值或破坏可见性
atomic.Value 存结构体？先确认字段是否可比较
atomic.Value 是存任意类型的唯一出口，但它有隐性约束：Store 的值必须可比较（能用于 ==），否则运行时报 sync/atomic: store of uncomparable value。
立即学习“go语言免费学习笔记（深入）”；
- 翻车组合：
struct{ cfg map[string]int }（map不可比较）、含sync.Mutex或chan字段的 struct - 安全做法：只存纯数据，如
struct{ Host string; Port int }；或改用指针 +json.RawMessage序列化后存 - 取值时类型必须严格一致：
v.Load().(*Config)不能错写成(*Other)，否则崩溃 - 注意 GC：
atomic.Value.Store不延长对象生命周期，若仅靠 atomic 引用，对象可能被回收
CompareAndSwapUint64 返回 false？不是失败，是并发常态
atomic.CompareAndSwapUint64(&x, old, new) 返回 false，只说明“此刻 x 的值不是 old”，不代表出错。这是无锁编程的设计前提，你得自己决定是否重试。
- 错误模式：
atomic.CompareAndSwapUint64(&c, v, v+1)后不检查返回值，以为设成功了 - 正确模式：用 for 循环自旋，读 → 算 → CAS → 不成再读，例如实现“只在小于阈值时递增”
- 高竞争下别空转：
runtime.Gosched()让出时间片，或time.Sleep(1ns)缓解 CPU 占用 - 别在循环里反复
var tmp uint64 = atomic.LoadUint64(&x)再传地址——局部变量地址生命周期不够，行为未定义
最常被忽略的其实是地址稳定性：哪怕类型、对齐、函数都对了，如果变量地址在函数栈上生成又消失，或者被 GC 回收，atomic 操作就会变成对野指针的读写——这时候 panic 都算客气的。
