Atomic.LoadUint64 要求 uint64 变量自然对齐（8 字节边界），否则在 32 位 ARM 等平台或启用 checkptr 时 panic；结构体中应将 uint64 置首字段或紧随 8 字节字段，避免未对齐。
Atomic.LoadUint64 读取值前必须确保对齐，否则 panic
Go 的 atomic 包要求操作的变量在内存中自然对齐（比如 uint64 必须落在 8 字节边界上），否则在某些平台（如 32 位 ARM 或启用了 -gcflags="-d=checkptr" 的构建）会直接 panic：panic: runtime error: invalid memory address or nil pointer dereference —— 实际是未对齐访问触发的运行时拦截。
- 结构体字段顺序会影响对齐：把
uint64放在结构体开头或紧跟在其他 8 字节字段后，避免被前面的byte或int32“挤偏” - 不要用
unsafe.Offsetof手动算偏移去原子操作嵌套字段，极易出错；优先把原子变量单独声明为顶层变量或结构体首字段 - 验证是否对齐：用
unsafe.Alignof(x)和unsafe.Offsetof(s.x)检查余数是否为 0
用 Atomic.CompareAndSwapUint64 实现无锁计数器时，别漏掉重试循环
很多人写 CAS 只调一次就完事，结果在高并发下丢更新。CAS 本质是“读-改-比-换”，中间可能被其他 goroutine 插入修改，失败是常态，必须显式重试。
- 典型错误写法：
atomic.CompareAndSwapUint64(&counter, old, old+1)后不检查返回值，也不重试 - 正确模式是：读当前值 → 计算新值 → CAS → 失败则重新读 → 循环直到成功
- 简单计数器可封装成函数，但注意别让编译器优化掉重读逻辑（Go 1.19+ 对
atomic.Load*有足够屏障，不用额外runtime.Gosched()）
for {
old := atomic.LoadUint64(&counter)
if atomic.CompareAndSwapUint64(&counter, old, old+1) {
break
}
}
Atomic.StorePointer 传入指针前，确保目标对象不会被 GC 回收
atomic.StorePointer 不会延长所存指针指向对象的生命周期。如果只靠它维持引用，对象可能在下一次 GC 时被回收，导致后续 LoadPointer 解引用崩溃。
- 常见场景：用原子指针管理配置快照、缓存句柄等，但忘记用全局变量、sync.Pool 或显式引用保持对象存活
- 安全做法：要么让对象本身是全局/静态生命周期（如
var cfg *Config），要么用sync.Pool管理临时对象，并在 Store 前保证 Pool.Get 返回的对象已被持有 - 不能依赖
runtime.KeepAlive补救——它只影响单次调用生命周期，无法跨 goroutine 保活
性能对比：Atomic vs Mutex，在什么情况下反而更慢？
原子操作不是银弹。当竞争激烈且操作本身很轻量（比如只加 1），atomic 通常更快；但若逻辑复杂、需要多步协调，或者 CAS 重试次数过高，反而不如一把锁清晰高效。
立即学习“go语言免费学习笔记（深入）”；
- CAS 高冲突时，CPU 在循环里空转（spin），浪费资源；Mutex 在阻塞时会让出时间片
- 写多读少场景下，用
atomic.Value替代频繁写共享结构体更合适；但若每次都要深拷贝大对象，序列化开销可能盖过原子优势 - 实测建议：压测时同时看
go tool pprof的 CPU profile 和runtime/pprof的 goroutine block 阻塞统计，别只盯吞吐数字
