atomic.storepointer不能存任意指针，因要求指针指向gc可追踪的堆内存，栈地址或uintptr中转会引发悬垂引用或panic。
为什么不能直接用 atomic.StorePointer 存任意指针
Go 的 atomic.StorePointer 和 atomic.LoadPointer 要求传入的指针必须指向“可被编译器追踪”的内存，也就是不能是栈上局部变量的地址，也不能是 unsafe.Pointer 转换来的、绕过 GC 的裸指针。常见错误是这么写：
func badExample() {
var x int = 42
atomic.StorePointer(&ptr, unsafe.Pointer(&x)) // ❌ panic: store of live pointer to stack
}
这是因为 &x 是栈地址，GC 不会管理它，而 atomic 操作可能跨 goroutine 持久化该指针，导致悬垂引用。正确做法是确保目标对象分配在堆上（比如用 new、&struct{} 或全局变量）。
atomic.CompareAndSwapPointer 的典型使用模式
无锁替换的核心是 CAS：仅当当前值等于预期旧值时，才原子地替换成新值。它不保证成功，必须循环重试。
- 第一个参数是目标指针的地址（
*unsafe.Pointer），不是值本身 - 第二个参数是“期望的旧值”，类型为
unsafe.Pointer；必须和当前值完全相等（bitwise）才触发替换 - 第三个参数是“拟写入的新值”，也必须是
unsafe.Pointer - 返回
bool表示是否成功；失败时需重新读取当前值再试
例如实现一个线程安全的单例指针更新：
var ptr unsafe.Pointer
func updateIfNil(newVal *int) bool {
for {
old := atomic.LoadPointer(&ptr)
if old != nil {
return false // 已存在，不覆盖
}
if atomic.CompareAndSwapPointer(&ptr, old, unsafe.Pointer(newVal)) {
return true
}
// CAS 失败：说明有其他 goroutine 先写入了，继续下一轮
}
}
如何安全地把结构体指针转成 unsafe.Pointer
不能对局部变量取地址传给 atomic，但可以对堆分配的对象这么做。最稳妥的方式是：
- 用
new(T)或&T{}显式分配在堆上（逃逸分析会保证） - 避免用
uintptr中转——uintptr不是 Go 的指针类型，GC 不识别，转回unsafe.Pointer后可能被回收 - 如果原数据是
*T类型，直接用unsafe.Pointer(p)即可，无需中间uintptr
反例（危险）：
// ❌ 危险：uintptr 不受 GC 保护，p 可能在转换前被回收 u := uintptr(unsafe.Pointer(p)) atomic.StorePointer(&ptr, unsafe.Pointer(uintptr(u)))
正例：
// ✅ 安全：p 是堆上 *MyStruct，直接转
p := &MyStruct{Field: 1}
atomic.StorePointer(&ptr, unsafe.Pointer(p))
性能与适用边界：别为了无锁而无锁
atomic 指针操作快，但只适合极简场景——比如只做一次初始化、或极少发生的切换。它不提供内存可见性以外的同步语义：
- 不保证新指针所指向的数据已“对其他 goroutine 可见”——你需要额外的 memory barrier 或配合
sync/atomic其他操作（如StoreInt64写个标志位） - 无法原子地更新指针 + 修改其字段；若需复合操作，
sync.Mutex往往更清晰、更不易出错 - 调试困难：没有栈信息、不支持
go tool trace追踪，竞态问题难复现
真正需要无锁指针替换的场景其实很少，比如 lock-free stack 的头节点更新、配置热加载中的原子切换。多数时候，先用 mutex 写清楚逻辑，压测发现瓶颈后再针对性优化。
最容易被忽略的一点：即使 atomic 操作成功，也不代表你通过该指针读到的字段值就是最新写入的——除非那些字段本身也是 atomic 访问，或者你用了 sync/atomic 提供的 full fence（比如 atomic.StoreInt64 配合 atomic.LoadInt64）来建立 happens-before 关系。
