compareandswappointer 是 go 无锁栈唯一可靠起点，因其提供指针级 cas 原子操作，支撑安全的“检查-修改”循环；其他原子操作无法保证该语义，易致链表断裂或 nil panic。
为什么 sync/atomic 的 CompareAndSwapPointer 是唯一靠谱起点
Go 没有提供原生的无锁数据结构，sync 包里所有东西（包括 Mutex、RWMutex）都是基于操作系统锁的。想写真正的无锁栈，只能靠 sync/atomic 底层原子操作，而其中能用于指针更新的只有 CompareAndSwapPointer —— 它是构建 CAS 循环的基础，其他函数如 StorePointer 或 LoadPointer 无法保证“检查-修改”原子性，直接用会崩。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference，往往是因为多个 goroutine 同时修改了栈顶指针，但没用 CAS 做校验，导致链表断裂或读到中间态指针。
- 必须用
unsafe.Pointer转换节点指针，不能直接传*node - 每次
Push/Pop都得在一个 for 循环里重试，直到CompareAndSwapPointer返回 true - 注意：Go 1.19+ 对
unsafe.Pointer转换加了更严的规则，不能从 slice header 或栈变量取地址再转，节点必须堆分配（即用&node{}）
如何避免 ABA 问题：用计数器还是版本号
纯指针 CAS 栈在 Go 中天然面临 ABA 问题：某个节点被弹出、回收、再分配为新节点、又被压入，此时旧的栈顶指针值“碰巧”相同，CAS 误判成功。Go 没有 std::atomic<shared_ptr></shared_ptr> 那种带引用计数的智能指针，也不能像 C/C++ 那样用双字 CAS（DCAS）。
实操中只有两个现实选择：
立即学习“go语言免费学习笔记（深入）”；
- 用
uintptr把指针和一个单调递增的计数器打包进一个uint64，高位存计数、低位存指针（需确保指针地址低比特对齐，通常用unsafe.Alignof检查），再用CompareAndSwapUint64；这是最常用也相对安全的做法 - 不解决 ABA，而是规避：禁止内存复用 —— 所有节点一旦
Pop就不再回收，靠 GC 清理。适用于生命周期短、吞吐不高的场景，简单但可能吃内存 - 不要尝试用
runtime.SetFinalizer延迟释放节点，它无法控制时机，反而加剧 ABA 风险
Pop 返回值为空时怎么判断是栈空还是竞争失败
无锁栈的 Pop 不能靠返回 nil 判定栈空，因为可能只是当前 goroutine 在 CAS 循环中被抢占，别的 goroutine 正在修改栈顶，你读到的是临时脏值。
正确做法是把“是否真正弹出成功”作为返回值的一部分：
- 函数签名建议为
func (s *Stack) Pop() (value interface{}, ok bool)，ok == false表示栈确实空，不是重试失败 - 关键逻辑：只有在 CAS 成功且旧栈顶非 nil 时才返回
ok = true；如果 CAS 失败，继续循环；如果某次读到top == nil，且下一次 CAS 仍失败（说明别人也没改它），才能确认栈空 - 别在循环里直接
return nil, false—— 这会导致调用方误以为栈空，实际只是抢不过别人
为什么生产环境慎用自研无锁栈
Go 调度器的 G-P-M 模型、GC 的写屏障、以及 runtime 对指针的强管控，让无锁结构比在 C/C++ 里更难写对。一个典型问题是：当 goroutine 在 CAS 循环中被抢占，长时间停在中间状态，会拖慢整个 P 的调度，甚至引发 GC STW 时间变长。
除非你满足以下全部条件，否则直接用 sync.Mutex + slice 更稳：
- 压测确认锁争用是瓶颈（pprof 显示
sync.Mutex.Lock占 CPU >15%） - 栈操作极频繁（>100k ops/sec）、且单次操作逻辑极轻（无 channel、无函数调用、无接口转换）
- 能接受内存不及时释放（节点不复用）或自己维护对象池
真实项目里，多数所谓“高并发栈”场景，其实是误判了瓶颈 —— 真正卡住的往往是后续的网络 I/O 或序列化，不是栈本身。
