atomic.loadint64读不到最新值是因为写端未用atomic.storeint64配对，普通赋值绕过内存屏障；compareandswapint64必须检查返回值；atomic.value仅保证整体替换原子性，不保护内部字段；atomic不一定比mutex快，需依争用程度和操作复杂度权衡。
Atomic.LoadInt64 为什么读不到最新值？
不是函数有问题，而是你没保证写操作也用原子指令——Atomic.LoadInt64 只对配对的 Atomic.StoreInt64 有效。普通变量赋值（比如 counter = 42）绕过内存屏障，CPU 缓存可能不刷新，读端永远看不到更新。
- 所有共享整数读写必须成对使用
Atomic.Load*和Atomic.Store*，不能混用普通赋值 - 结构体字段不能直接原子读写，得用
Atomic.Value或拆成独立原子变量 - 在非同步 goroutine 中反复调用
LoadInt64前，确认写端确实调用了StoreInt64，而不是用了+=这类非原子操作
CompareAndSwapInt64 失败却不报错，怎么调试？
CompareAndSwapInt64 返回 bool，它不 panic、不 log，失败就静默返回 false。很多人忽略返回值，结果逻辑卡死或数据覆盖。
- 必须检查返回值：
if !atomic.CompareAndSwapInt64(&val, old, new) { /* 处理冲突 */ } - 典型场景是实现无锁栈/队列，失败意味着其他 goroutine 已抢先修改，需重试（loop + load）或降级为加锁
- 注意
old参数必须是「当前期望值」，不是初始值；如果中间有别的写入，old就失效了
Atomic.Value 能存 map 或 struct 吗？
能存，但危险——Atomic.Value 只保证“替换整个值”是原子的，不保护内部字段。存 map[string]int 后直接 m["k"] = 1 会并发 panic。
- 只适合存不可变对象（如
struct{ x, y int }）或指针（*MyConfig），且后续只读不改内部 - 要存可变 map，得用
sync.RWMutex包一层，或者换sync.Map（但它不是原子变量，API 不同） - 每次
Store都分配新对象，频繁更新大结构体会增加 GC 压力
用 atomic 替代 mutex 一定更快吗？
不一定。在低争用（goroutine 很少同时碰同一变量）时，atomic 确实快；但高争用下，CompareAndSwap 自旋重试反而比 mutex 的系统级休眠更耗 CPU。
立即学习“go语言免费学习笔记（深入）”；
- 简单计数器、状态标志位（
int32表示 running/stopped）适合 atomic - 需要多步逻辑（如“读 A → 判断 → 写 B → 清 C”）就别硬上 atomic，容易出竞态，老实用
sync.Mutex - benchmark 要跑足够长时间（至少 10ms+），且控制 goroutine 数量，否则测不出真实差异
真正难的是判断哪些变量值得原子化、哪些操作链必须保序——这没法靠工具自动发现，得看数据流和业务语义。
