atomic.addint64 要求参数为 *int64，因 go 用类型系统强制并发安全边界；需声明 var count int64 并传 &count，读取后按需转 int；compareandswapint64 不防 aba，需手动加版本号或改用锁；atomic.loaduint64 不保证实时最新值，仅保顺序一致性；atomic.value 仅保障整体存取原子性，内部结构须不可变或另加保护。
atomic.AddInt64 为什么不能直接用 int？
Go 的 atomic 包所有操作都要求类型严格匹配，AddInt64 只接受 *int64，传 int 或 *int 会编译报错：first argument to atomic.AddInt64 must be *int64。这不是疏忽，是 Go 故意用类型系统守住并发安全的边界。
常见错误：把普通计数器变量声明成 var count int，然后想直接 atomic.AddInt64(&count, 1) —— 这行不通。
- 必须显式声明为
int64：var count int64 - 指针取址后才能传入：
atomic.AddInt64(&count, 1) - 如果原始业务逻辑依赖
int（比如切片长度、循环上限），记得在读取后做显式转换：int(count)，但注意避免在原子读写中间插入非原子逻辑
CompareAndSwapInt64 怎么避免“ABA 问题”？
CompareAndSwapInt64 是无锁编程的核心，但它本身不解决 ABA 问题：即某个值从 A→B→A，CAS 误判为“没变过”。Go 标准库不内置版本号或标记位机制，得靠你自己设计。
典型场景：实现一个简易的带状态切换的计数器（如“启用/禁用中”），只靠一个 int64 表达状态容易出错。
立即学习“go语言免费学习笔记（深入）”；
- 别只存纯数值；加个低几位当状态标志，比如用
int64高 56 位存计数值，低 8 位存状态码 - 用
atomic.LoadUint64+ 位运算读取组合值，再用atomic.CompareAndSwapUint64做带掩码的原子更新 - 如果业务允许，更简单的方式是换用
sync.Mutex或sync.RWMutex—— 不是所有地方都值得上无锁
atomic.LoadUint64 读取时为什么有时看到“旧值”？
这是正常现象。atomic 提供的是“顺序一致性”（sequential consistency）模型，不是实时同步。它保证所有 goroutine 看到的操作顺序是一致的，但不保证你 Load 的那一刻一定是最新的 —— 尤其在高竞争、多核缓存未及时刷新时。
常见误解：以为 atomic.Load 等价于“立刻拿到最新写入值”，其实它只是防止了数据撕裂和重排序，不提供“强实时性”。
- 如果你需要“等待直到某条件成立”，别轮询
Load，改用sync.WaitGroup或channel - 频繁读+极少写的场景，
atomic没问题；但读写比接近 1:1 时，缓存行争用反而可能比sync.RWMutex更慢 - 调试时看到旧值，先确认是否真有其他 goroutine 在写；用
go tool trace观察调度和原子操作实际执行时间点
用 atomic.Value 存 map 或 struct 安全吗？
安全，但仅限“整体替换”，不能对内部字段做并发修改。atomic.Value 只保证 Store 和 Load 操作本身原子，不递归保护内部数据结构。
典型翻车现场：存一个 map[string]int，多个 goroutine 同时 Load 出来后直接往里 put —— panic：concurrent map writes。
- 存之前先深拷贝或构造不可变副本：
v.Store(mapCopy(oldMap)) - 若需频繁更新内部字段，别用
atomic.Value，改用sync.Map（适合读多写少）或带锁封装 -
atomic.Value对nil支持良好，但首次Store后类型就固定了，后续Store必须同类型，否则 panic：Store of inconsistent type
atomic。 
