go原子指针操作仅支持unsafe.pointer类型，需通过其作为中转容器存取其他指针；因gc安全与内存对齐限制，禁止直接对int等类型使用atomic.storepointer/loadpointer。
Go 的 atomic.StorePointer 和 atomic.LoadPointer 不能直接操作普通指针
你写 atomic.StorePointer(&p, unsafe.Pointer(&x)) 看似合理，但只要 p 是 *T 类型（比如 *int），就会编译失败：类型不匹配。Go 的原子指针操作只接受 *unsafe.Pointer 作为第一个参数，不是任意指针类型。
真正能用的只有：*unsafe.Pointer 变量本身 —— 它是原子操作的“容器”，里面存的是其他对象的地址。所以得先声明一个中间容器：
var ptr unsafe.Pointer atomic.StorePointer(&ptr, unsafe.Pointer(&x))
后续读取也必须从这个 ptr 出发，再转回原类型：
xPtr := (*int)(atomic.LoadPointer(&ptr))
- 别试图对
*int、*string等直接调用原子函数，Go 类型系统会拦住你 -
unsafe.Pointer是唯一被sync/atomic指针系列函数认可的“可原子化”指针类型 - 每次转换都要显式强制类型转换，没有隐式提升，少写一步就编译不过
为什么非要用 unsafe.Pointer 中转？绕不开的内存对齐和 GC 问题
Go 运行时需要知道每个指针指向哪里，才能正确扫描堆、移动对象、回收内存。如果允许任意指针类型被原子更新，GC 可能正在遍历旧指针时，另一个 goroutine 已把它替换成新地址 —— 且这个新地址还没被标记为存活，导致误回收。
立即学习“go语言免费学习笔记（深入）”；
用 unsafe.Pointer 中转，本质是把“指针值”当作纯整数来交换，避开 GC 跟踪；而最终转成具体类型（如 *int）的那一刻，才重新进入 GC 视野。这是 Go 在并发安全与内存安全之间做的明确取舍。
- 所有通过
atomic.LoadPointer读出的unsafe.Pointer，必须在使用前立刻转成目标类型并确保对象还活着 - 如果你在原子读之后、类型转换之前发生了 GC，且原对象已不可达，那转换后的指针就是悬垂指针 —— 不崩溃，但行为未定义
- 常见做法：配合引用计数或对象池，确保被原子引用的对象生命周期长于指针使用期
atomic.CompareAndSwapPointer 的第三个参数必须是当前值的精确快照
这个函数不会帮你“读-改-写”，它只做原子比较和交换。你传进去的旧值，必须是上次 LoadPointer 或其他方式拿到的精确值，否则交换失败。很多人以为可以传个“大概值”或 nil 判断，结果一直返回 false。
old := atomic.LoadPointer(&ptr)
new := unsafe.Pointer(&y)
if !atomic.CompareAndSwapPointer(&ptr, old, new) {
// 失败了，说明期间有别的 goroutine 改过 ptr
// 你得重试，或者放弃
}
- 不能传
nil当旧值去“假设它还是空”，除非你 100% 确定没别的 goroutine 写过 - 无锁编程里，CAS 失败是常态，得设计好重试逻辑（比如循环 + 条件退出）
- 注意：
CompareAndSwapPointer返回bool，不抛错，也不阻塞，失败了就靠你自己处理
替代方案：什么时候该放弃原子指针，改用 sync.Mutex 或 sync.RWMutex
原子指针适合极简场景：单个指针的读写，且读多写少、写操作非常轻量（比如切换配置、更新缓存头）。一旦涉及多个字段协同更新、结构体复制、或需要保证读写顺序一致性，原子指针很快就不够用了。
比如你想原子地更新一个 *Config 同时还要更新关联的 version 计数器 —— atomic 包没有“多字段原子更新”接口，强行拼凑容易出竞态。
- 如果结构体不大（atomic.Value 存整个结构体指针，它内部封装了
unsafe.Pointer操作，且支持任意类型 - 如果读写频率接近，或写操作要加日志、校验、回调，
sync.RWMutex更清晰、更不易出错 - 别为了“看起来快”硬上原子操作；实测发现，多数业务代码里 mutex 的开销远低于逻辑错误带来的调试成本
真正难的从来不是怎么写原子操作，而是判断某个指针更新，是否真的需要脱离 GC 视角、裸露地址、手动保活 —— 这部分稍有不慎，就是深夜收告警的时间点。
