atomic.swap仅适用于无条件状态切换、计数器重置、指针替换等明确场景，不可替代锁或拼无锁结构；关键区别在于swap无条件覆盖并返回旧值，而compareandswap需满足预期值才更新，滥用swap易引发内存顺序与数据竞争问题。
atomic.Swap 不是用来“替代锁”的万能工具，它只适合极少数明确场景：状态标志切换、无锁计数器重置、指针级对象替换。滥用它拼无锁结构，90% 的问题出在内存顺序和数据竞争上，而不是函数本身。
什么时候该用 atomic.Swap 而不是 atomic.CompareAndSwap
关键区别在于你是否需要“条件性更新”。atomic.Swap 是无条件覆盖并返回旧值；atomic.CompareAndSwap 是“仅当当前值等于预期值时才更新”，带校验逻辑。
- 用
atomic.Swap：比如服务从running切到stopping，你不在乎之前是什么状态，只要立刻换掉并拿到旧状态做清理 ——old := atomic.SwapInt32(&state, STOPPING) - 用
atomic.CompareAndSwap：比如实现一个“仅当计数器为 0 时才允许关闭”的守门逻辑 ——atomic.CompareAndSwapInt32(&counter, 0, -1) - 别混用：对同一变量，不能一部分 goroutine 用
Swap写，另一部分用普通赋值（如state = 1），这会破坏原子性保证
atomic.SwapUint64 和 atomic.SwapPointer 的类型陷阱
Go 对原子操作的类型检查非常严格，尤其是指针类操作。编译期不会报错，但运行时可能 panic 或行为异常。
-
atomic.SwapUint64只接受*uint64，传*int64会编译失败；如果变量是uint64但你用atomic.LoadInt64读，结果未定义 -
atomic.SwapPointer参数必须是*unsafe.Pointer，且目标类型要一致。常见错误：把*Node强转成unsafe.Pointer后再转回，中间若发生 GC 移动或逃逸，地址失效 - 更安全的替代：用
atomic.Value替代atomic.SwapPointer做整块对象替换，它内部已处理好类型擦除与指针安全
Swap 类操作在无锁队列/栈里为什么容易翻车
单纯靠 Swap 实现无锁链表节点插入或删除，几乎必然出错。它不提供内存屏障语义，也不保证其他字段的可见性。
- 典型坑：你用
atomic.SwapPointer(&head, newNode)换头节点，但newNode.next字段是普通写入 —— 其他 goroutine 可能读到 head 已更新，却看到next还是 nil - 正确做法：所有相关字段（如
next、prev）必须统一用atomic.StorePointer/atomic.LoadPointer访问，且需搭配runtime.KeepAlive防止编译器优化掉关键读写 - 实际建议：除非业务极度敏感且团队有资深无锁经验，否则优先用
sync.Mutex或sync.RWMutex；atomic.Swap更适合作为“状态快照+切换”这类单点操作
真正难的从来不是调用哪个函数，而是判断“这个变量的所有访问路径是否都被原子操作覆盖”，以及“内存顺序是否被隐式破坏”。哪怕只漏掉一处普通读写，整个无锁设计就失去意义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
