热路径无锁队列必须基于sync/atomic.CompareAndSwapPointer搭配Michael-Scott算法和dummy节点，因channel底层含mutex、会阻塞调度且无法细粒度控制内存与性能；手写需严格使用atomic.LoadPointer、避免ABA需runtime.KeepAlive或sync.Pool生命周期管理，否则压测易panic或丢数据。
热路径无锁队列在 Go 中不能靠手写汇编或裸指针操作实现，必须基于 sync/atomic 的 CompareAndSwapPointer 搭配链表结构，且必须用 Michael-Scott 算法骨架——否则不是真无锁，而是伪并发安全。
为什么不能直接用 channel 当热路径无锁队列
channel 虽然并发安全、开箱即用，但它底层有锁（hchan 结构体含 mutex 字段），且缓冲区满/空时会触发 goroutine 阻塞和调度器介入。热路径意味着每秒数万次入队/出队，此时：
- channel 的锁争用会暴露（尤其 len(ch) 或 select 非阻塞判断时）
- 内存分配不可控（make(chan int, N) 分配的是 runtime 管理的环形缓冲，无法复用节点）
- 无法做细粒度性能观测（比如单次 CAS 失败率、tail 滞后距离）
所以热路径必须自己管理内存和指针，channel 只适合中低频协调或原型验证。
CompareAndSwapPointer 必须配合 atomic.LoadPointer 和 dummy 节点
Michael-Scott 算法依赖两个原子指针：head 和 tail，初始都指向一个 dummy 节点。所有读写都必须用 atomic 函数，混用普通赋值会导致数据竞争或重排序失效：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次读
tail必须用atomic.LoadPointer(&q.tail)，不能直接解引用*q.tail - 更新
tail.next前，要先用atomic.CompareAndSwapPointer(&tailNode.next, nil, newNode)，失败就重试 - 更新
tail指针本身也得用CompareAndSwapPointer，但允许“滞后”——其他线程可协助推进（这是算法关键） - dummy 节点不能是栈变量（如
var d Node），必须堆分配（&Node{}），否则 GC 可能回收
CAS 失败后不能忙等，得加 runtime.Gosched() 或短 sleep
在高争用下，CAS 失败是常态。如果失败后立即重试（busy loop），会把 P 绑死在当前 M 上，挤占其他 goroutine 时间片，反而降低吞吐：
- 纯
for {}重试 → CPU 占用飙升，延迟毛刺明显 - 每次失败后调用
runtime.Gosched()→ 主动让出时间片，调度器可切走 - 更优做法：失败 3–5 次后
time.Sleep(1 * time.Nanosecond)，利用内核纳秒级调度精度降压 - 注意：不要用
time.Sleep(0)，它不保证让出，Go 1.23+ 已明确不推荐
ABA 问题必须靠节点生命周期管理，不是加版本号
Go 没有带 tag 的 CAS，CompareAndSwapPointer 无法防 ABA。但实际中不必硬上版本号字段——因为无锁队列节点一旦入队，只可能被出队一次，之后不再复用：
- 节点必须从
sync.Pool获取，但出队后不能直接Put回池（可能正被其他线程读 next） - 正确做法：出队成功后，保留对旧节点的引用至少一个 GC 周期；或用
runtime.KeepAlive(oldNode)防止提前回收 - 避免用
unsafe.Pointer在栈上构造节点（如unsafe.Pointer(&localVar)），GC 无法跟踪，极易悬垂 - 若需复用节点（如固定大小对象池），必须确保：入队前节点
next已清零，且所有 goroutine 对该节点的访问已全部退出
真正容易被忽略的不是算法本身，而是节点内存的可见性边界和 GC 可达性——写错一行 atomic.LoadPointer 或漏掉一个 runtime.KeepAlive，就会在压测时随机 panic 或丢数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
