sync.mutex栈不是lock-free，因其持有者panic或被抢占时其他goroutine会卡在lock()上；真lock-free必须用atomic.compareandswappointer配合uintptr打包指针与版本号防aba，且节点须堆分配、循环中每次重读状态。
Go 里实现并发安全的栈，sync.Mutex 最简单但不算无锁；真要 Lock-Free，必须用 atomic.CompareAndSwapPointer 配合指针打包和版本号，否则大概率遇到 ABA、GC 提前回收或 panic。
为什么 sync.Mutex 栈不是 Lock-Free
Lock-Free 的定义不是“没写 lock”，而是“任意 goroutine 崩溃、被抢占或长期暂停，都不影响其他 goroutine 完成操作”。sync.Mutex 一旦持有者 panic 或调度延迟，其他 goroutine 就卡在 Lock() 上——这直接违反定义。它依赖操作系统互斥原语，带来上下文切换和阻塞，只是“并发安全”，不是“无锁”。
atomic.CompareAndSwapPointer 是唯一可用的指针级 CAS 入口
Go 不允许手写汇编 CAS，也不支持对结构体字段直接原子操作。sync/atomic 只提供有限函数，其中能操作任意堆对象地址的只有 CompareAndSwapPointer，且必须配对使用 unsafe.Pointer：
- 节点必须堆分配：
newNode := &node{...}，不能是栈上局部变量取地址 - 字段类型要干净：节点结构体里不能含
interface{}、map、slice等需 GC 跟踪的字段，否则 GC 可能漏掉引用 - 传参必须严格匹配：
&s.head是*unsafe.Pointer，旧值和新值都得是unsafe.Pointer，不能混用*node - 失败后不能丢弃
newNode：它可能正被其他 goroutine 读取，CAS 失败也不代表它无效
必须防 ABA，Go 没有内置带版本的原子指针
单纯用 CompareAndSwapPointer 做栈顶替换，会掉进 ABA 陷阱：A 读到 top = X，B 弹出 X 又压入新节点 Y（地址复用为 X），A 再 CAS 成功，却误认为栈顶还是原来的 X。Go 没有 std::atomic<shared_ptr></shared_ptr> 那种带版本的封装，得自己打包：
- 用
uintptr高位存指针、低位存版本号（如低 8 位） - 每次 CAS 前必须先
atomic.LoadUintptr拆出当前指针和版本 - 构造新值时版本号 +1，再用
atomic.CompareAndSwapUintptr更新 - 不能对
unsafe.Pointer直接做位运算，必须转成uintptr后操作
示例节点结构：type lockFreeStack struct { head uintptr }，其中 head 存的是 (uintptr)(unsafe.Pointer(node)) | version。
CAS 循环里最容易忽略的三件事
CAS 是乐观策略，失败就重试，但重试逻辑写错会导致静默错误或崩溃：
- 每次循环开头必须重新
atomic.LoadPointer或atomic.LoadUintptr，不能缓存旧值跨轮次使用 - Pop 时若读到空栈（
nil或版本不匹配），必须立即返回，不能继续解引用next - 所有节点指针读写都必须走
atomic.LoadPointer/atomic.StorePointer，混用普通赋值会触发数据竞争，go run -race会报 - 别在循环里做接口转换、分配内存或调用函数——这些操作拉长临界区，放大竞争，拖慢整个栈
真正难的不是写对一次 CAS，而是让每个节点在逻辑上“删除”后，还能被其他 goroutine 安全访问一小段时间——Go 的 GC 机制让它比 C 更隐蔽，也更难调试。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
