因为底层汇编指令（如x86的CMPXCHG）必须操作内存地址，传值会丢失地址信息，导致编译报错且无法执行原子操作。
为什么 atomic.CompareAndSwapInt64 要求传入指针而不是值？
因为底层汇编指令（如 x86 的 CMPXCHG）必须操作内存地址，不是寄存器里的副本。传值会丢失地址信息，编译直接报错：cannot call non-exported function atomic.cas64（实际错误更可能是 first argument to atomic operation must be addressable）。
实操建议：
- 变量必须可寻址：不能对字面量、map value、函数返回值等取地址，比如
atomic.CompareAndSwapInt64(&123, 123, 456)非法 - 结构体字段需确保整个结构体在堆上或显式取址，嵌套字段如
obj.x可用&obj.x，但objPtr.x（objPtr 是 *T）必须写成&objPtr.x，不能写&(*objPtr).x—— 虽等价但易读性差且可能触发逃逸分析误判 - 切片元素不支持原子操作：
&slice[i]在 slice 扩容后失效，地址可能被复用，导致 CAS 作用于错误内存位置
atomic.Value 能否安全存储指针类型？
能，但必须注意语义——atomic.Value 存的是「接口值」，不是原始指针。它内部用 unsafe.Pointer 做类型擦除，所以存 *int 没问题，但每次 Load() 返回的是 interface{}，需要类型断言还原。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 存了
*MyStruct，却用v.Load().(*MyStruct)断言失败：因为存的时候是interface{}包装的指针，但若原变量被回收或重新赋值，指针仍有效，只是所指内容可能已变 - 并发写入不同类型的值（比如先存
*int，再存string），会导致后续所有Load()后的类型断言 panic - 性能影响：每次
Store()触发一次接口值构造和内存拷贝；频繁更新大结构体时，比直接用atomic.Pointer[T]（Go 1.19+）开销更大
Go 1.19+ 的 atomic.Pointer[T] 和老式 unsafe.Pointer + atomic.CompareAndSwapPointer 有何区别？
核心区别是类型安全与可读性。atomic.Pointer[T] 是泛型封装，编译期检查类型，避免手动做 unsafe.Pointer 转换出错；而老方式靠人脑保证 uintptr 和指针来回转换的一致性。
使用场景与参数差异：
-
atomic.Pointer[T].CompareAndSwap(old, new *T)：参数必须同为*T，编译器拦住类型错配；老方式要写atomic.CompareAndSwapPointer(&p, unsafe.Pointer(old), unsafe.Pointer(new))，容易漏掉unsafe.Pointer转换或顺序颠倒 - 兼容性：Go 1.19+ 推荐用
atomic.Pointer[T]；低于此版本只能用老方式，且需自己处理nil到unsafe.Pointer(nil)的转换 - 容易踩的坑：
atomic.Pointer[T]的Load()返回*T，不是T；若 T 是大结构体，别误以为返回的是副本——它仍是原始地址上的指针
CAS 失败后重试逻辑里，为什么不能无条件循环调用 Load()？
因为 Load() 本身不保证“看到最新值”——在弱内存模型 CPU（如 ARM）上，连续两次 Load() 可能命中缓存并返回过期副本，导致 CAS 循环永远失败。
实操建议：
- 必须在 CAS 失败后，用
Load()获取当前值，再基于这个值计算 next；不要跳过这一步直接重试旧值 - 若逻辑复杂（比如需原子地增某个字段），优先考虑
atomic.AddInt64等专用函数，而非手写 CAS 循环 - 极端高争用场景下，简单自旋可能饿死其他 goroutine；可加入
runtime.Gosched()或短 sleep，但要小心降低吞吐——这不是通用解法，而是特定瓶颈的权衡
最常被忽略的一点：CAS 不是万能锁替代品。它只适合单个字段的无锁更新；一旦涉及多个字段协同变更（比如余额扣减 + 订单状态更新），就必须回归 mutex 或更高层抽象。硬用 CAS 拼凑多步逻辑，极易引入 ABA 问题或状态不一致，而且 debug 成本远高于加一行 mu.Lock()。
