atomic.LoadUint64总返回0通常因传入未初始化或栈上临时变量的地址；须确保指针指向包级变量或堆分配的持久内存。
atomic.LoadUint64 为什么总返回 0？检查是否用了未初始化的指针
常见错误是把 uint64 变量地址传给 atomic.LoadUint64，但变量本身没初始化，或者传了栈上临时变量的地址。该函数只接受 *uint64，且要求地址有效、生命周期足够长。
- 确保变量声明为包级变量或显式分配在堆上（如用
new(uint64)） - 不要对局部变量取地址后传给原子操作函数，逃逸分析可能不保证安全
- 确认没有重复声明同名变量覆盖了原始指针（比如循环里
var x uint64; p := &x）
var counter uint64 = 100
// ✅ 正确：包级变量，地址稳定
fmt.Println(atomic.LoadUint64(&counter))
// ❌ 错误示例（编译能过，但行为未定义）：
// func bad() {
// var x uint64 = 42
// fmt.Println(atomic.LoadUint64(&x)) // x 在函数返回后失效
// }
CompareAndSwapInt32 的失败不是 bug，而是并发控制的正常反馈
atomic.CompareAndSwapInt32 返回 bool 表示“旧值匹配且已更新”。它不抛异常，也不重试——这是设计使然。你得自己决定是否重试、何时放弃、要不要加 backoff。
- 典型场景是实现无锁计数器、状态机跃迁（如从
0 → 1表示“启动中”） - 如果期望“一定成功”，需配合 for 循环 + 条件判断，即 CAS 自旋
- 注意：过度自旋会浪费 CPU，高竞争下建议结合
runtime.Gosched()或短时休眠
var state int32 = 0
for !atomic.CompareAndSwapInt32(&state, 0, 1) {
// 当前 state 不是 0，说明已被其他 goroutine 占用
// 可选择继续等待、返回错误，或稍作让出
runtime.Gosched()
}
StorePointer 和 LoadPointer 必须配对使用，且类型要严格一致
Go 的 atomic.StorePointer 和 atomic.LoadPointer 操作的是 unsafe.Pointer，不进行类型检查。一旦存入和读出的底层结构不匹配（比如存了 *A 却当 *B 读），就会触发未定义行为，甚至崩溃。
- 务必用
unsafe.Pointer(&x)存，用(*T)(atomic.LoadPointer(&p))读，且T必须和存入时的原始类型完全一致 - 不能跨包直接传递裸
unsafe.Pointer，容易丢失类型上下文 - Go 1.19+ 支持泛型封装，可写个类型安全的 wrapper，避免手写
unsafe
var ptr unsafe.Pointer
type Config struct{ Timeout int }
cfg := &Config{Timeout: 5}
atomic.StorePointer(&ptr, unsafe.Pointer(cfg))
// ✅ 正确读取
loaded := (*Config)(atomic.LoadPointer(&ptr))
fmt.Println(loaded.Timeout) // 5
不要用 atomic 替代 mutex 处理复杂状态，尤其涉及多个字段时
原子操作只保证单个值的读写线性化，无法原子地更新两个关联字段（如 count 和 sum）。试图用多个 atomic 操作拼凑“逻辑原子性”，大概率导致中间态被其他 goroutine 观察到，引发数据不一致。
- 当需要保护一组字段、或执行多步条件逻辑（如“若余额 > X 则扣款并记录日志”），必须用
sync.Mutex或sync.RWMutex -
atomic适合高性能热点路径：计数器、开关标志、单指针替换、序列号生成等 - 一个易忽略点：
atomic不提供内存屏障之外的同步语义，比如不会阻止编译器或 CPU 重排非原子访问
真正难的不是调用哪个函数，而是判断“这里到底需不需要原子性”以及“这个变量的修改是否独立于其他状态”。很多并发 bug 源于过早优化——先用 sync.Mutex 写正确，再看 profile 数据决定是否值得换成 atomic。
