sync.mutex不是单向链表并发安全的最优解，因其锁粒度粗导致吞吐量低，且易引发死锁或漏删；需用atomic.compareandswappointer等cas操作无锁更新next指针，避免map误用、nil解引用及atomic.value存储含指针结构体带来的悬垂指针与性能问题。
为什么 sync.Mutex 不是单向链表并发安全的最优解
因为锁粒度太粗，Insert 或 Delete 时整个链表被阻塞，吞吐量掉得厉害；更麻烦的是，一旦遍历中加锁（比如边查边删），极易写出死锁或漏删逻辑。原子操作不是为了炫技，而是为了解决「多个 goroutine 同时修改指针」这个本质问题——链表节点的 next 字段必须被无锁更新。
常见错误现象：panic: concurrent map read and map write（误用 map 模拟链表）、遍历时 nil pointer dereference（一个 goroutine 刚删掉节点，另一个还没来得及检查就解引用）。
实操建议：
- 放弃用
map[int]*Node模拟链表——它天生不满足“单向”和“有序遍历”语义，且并发读写 map 会直接 panic - 每个节点的
next字段必须声明为unsafe.Pointer或*Node+atomic.Value，但后者有接口逃逸开销，不推荐 - 核心是用
atomic.CompareAndSwapPointer实现 CAS 更新，而不是靠锁保序
atomic.CompareAndSwapPointer 怎么安全替换 next 指针
它不是“设置”，而是“条件更新”：只有当前值等于预期旧值时，才把指针设成新值。这正好对应链表插入/删除的原子性要求——比如在 A→B 之间插入 C，必须确保 A 的 next 还指着 B，才能把它改成 C；否则说明别人已经动过，得重试。
立即学习“go语言免费学习笔记（深入）”；
使用场景：实现无锁 PushFront（头插）最简单，InsertAfter 和 Delete 需要循环 CAS，不能只试一次。
实操建议：
- 头插可单次 CAS 完成：
atomic.CompareAndSwapPointer(&head, old, unsafe.Pointer(newNode)) - 删除某节点 X（已知前驱 P）时，必须循环重试：
for { old := atomic.LoadPointer(&p.next); if old == unsafe.Pointer(x) { if atomic.CompareAndSwapPointer(&p.next, old, atomic.LoadPointer(&x.next)) { break } } else { p = (*Node)(old) } } - 永远不要直接写
p.next = x.next——这行代码在并发下不是原子的，中间可能被其他 goroutine 打断
为什么不能用 atomic.Value 存整个节点
atomic.Value 只能安全存储“可复制”的值，而链表节点包含指针字段（next *Node），一旦用 Store 存进去，Go 运行时会做深拷贝（实际是反射遍历+复制），导致你存进去的 next 指针在副本里变成悬垂指针——原节点被 GC 后，副本里的指针就指向了非法内存。
性能影响明显：每次 Load 都触发反射，比纯指针 CAS 慢 10 倍以上；兼容性上，Go 1.19+ 对 atomic.Value 的泛型支持也没解决底层指针失效问题。
实操建议：
- 绝对不要对含指针的结构体（如
type Node struct { data int; next *Node }）调用atomic.Value.Store - 如果非要用
atomic.Value，只能存uintptr或unsafe.Pointer，但这就回到了原始指针操作，不如直接用atomic.*Pointer系列 - 测试时加
-gcflags="-m"看是否发生堆分配，若出现 “moved to heap” 就说明触发了逃逸，atomic.Value正在悄悄拖慢你
真实删除逻辑里最容易漏掉的空检查
不是检查节点本身是不是 nil，而是检查 CAS 前后 next 是否被其他 goroutine 改写过。比如你想删掉 head 后第二个节点，从 head 开始遍历，走到第一个节点时读到 next 是 B，但刚准备 CAS 更新它的 next，B 就被别人删掉了——此时 B 的 next 可能是 nil 或乱值，直接拿来 CAS 会失败甚至崩溃。
容易踩的坑：用 == 比较两个 *Node 是否相等，但没考虑其中一个是刚 new(Node) 出来的零值，next 是 nil，而另一个是已初始化节点，next 是有效地址，比较结果永远 false，导致无限循环。
实操建议：
- 所有指针比较必须用
atomic.LoadPointer读取，再转成*Node做逻辑判断，禁止直接访问字段 - 删除循环里每次迭代前都重新读前驱的
next，别缓存中间变量 - 在测试中故意用
runtime.Gosched()插入调度点，暴力暴露竞态——标准go test -race对这种细粒度指针操作不一定能捕获
真正的难点不在写对 CAS，而在构造出足够多的“时间窗口”让各种删除路径交叉执行；稍不注意，漏掉一次 atomic.LoadPointer 就会让整条链表进入不可预测状态。
