atomic.loaduint64 更快因其是单条带 lock 前缀的 cpu 指令，无调度、上下文切换或锁竞争开销；而 mutex.lock() 在争抢激烈时可能休眠/唤醒，开销高一个数量级。
Atomic.LoadUint64 为什么比 mutex.Lock() 更快
因为 Atomic.LoadUint64 是单条 CPU 指令（如 x86 的 mov + lock 前缀），不涉及操作系统调度、上下文切换或锁队列竞争；而 mutex.Lock() 在争抢激烈时可能触发休眠/唤醒，开销高一个数量级。
适用场景：只读高频访问的计数器、状态标志、配置快照等——只要不依赖“读-改-写”原子性，就优先用 Atomic。
- 不要用
Atomic.LoadUint64替代sync.Mutex保护结构体字段组合（比如同时读user.Name和user.Age） - 注意内存顺序：
Atomic.LoadUint64默认是 sequentially consistent，但若需更松散语义（如 relaxed load），go 不直接暴露，别强行模拟 - 32 位系统上
uint64的 atomic 操作仍要求 8 字节对齐，否则 panic：“panic: runtime Error: invalid memory address”
CompareAndSwapUint64 处理“读-改-写”必须加循环重试
Atomic.CompareAndSwapUint64 不是“自动重试”，它只尝试一次：成功返回 true，失败返回 false。漏掉循环逻辑，会导致更新静默丢失。
典型错误写法：Atomic.CompareAndSwapUint64(&counter, old, old+1) 只调一次，多 goroutine 下大概率失败且不补救。
立即学习“go语言免费学习笔记（深入）”；
- 正确模式是
for { old := Atomic.LoadUint64(&counter); if Atomic.CompareAndSwapUint64(&counter, old, old+1) { break } } - 如果更新逻辑复杂（比如要校验业务条件），把判断逻辑放在循环内，避免在 CAS 外计算新值后被其他 goroutine 覆盖
- 极端高冲突场景下，自旋太久会浪费 CPU，此时应退回到
sync.Mutex或引入指数退避
atomic.Value 不能直接存普通 Struct，必须指针或接口
atomic.Value 的 Store 和 Load 方法只接受 Interface{}，但底层对大对象拷贝敏感。直接存 struct 会复制整个值，且无法保证字段级原子性。
常见误用：var v atomic.Value; v.Store(MyStruct{A: 1, B: 2}) —— 看似可行，但并发读写时 A 和 B 可能来自不同版本。
- 安全做法是存指针：
v.Store(&MyStruct{A: 1, B: 2})，读取后解引用，确保看到一致快照 - 或者用
sync.map替代，当需要频繁增删键且 value 本身不变时，它比atomic.Value+ map 组合更省心 -
atomic.Value的Store不能用于 nil 接口，否则 panic：“reflect.Value.Interface: cannot return unaddressable value”
Go 1.19+ 的 atomic.AddUint64 返回新值，旧代码可能少接返回值
Go 1.19 起，atomic.AddUint64 改为返回更新后的值（之前版本无返回）。升级后若原代码写成 atomic.AddUint64(&x, 1) 且没用返回值，编译仍过，但语义已变——你可能以为它只加不返，实际它返了，只是被忽略。
- 检查所有
atomic.Add*调用：是否依赖旧版“无返回”假定？比如日志里打印旧值，现在得先Load再Add - 若需旧值，必须显式先
old := Atomic.LoadUint64(&x)，再Atomic.AddUint64(&x, 1)，不能靠返回值反推 - 这个变更也适用于
atomic.AddInt32/atomic.AddInt64，但atomic.AddUint32在 32 位平台仍是伪原子（用 mutex 模拟），性能差，别在 hot path 用
真正难的不是选 Atomic 还是 Mutex，而是判断“某个读写组合是否真的能拆成独立原子操作”。多数业务逻辑天然耦合，硬上 Atomic 反而引入隐蔽的竞态——这时候老老实实用 sync.Mutex，反而最省调试时间。