atomic.loadpointer必须传*unsafe.pointer而非&变量，因go类型系统限制直接取址unsafe.pointer变量；正确做法是先声明unsafe.pointer变量再取其地址，否则编译报错。
atomic.LoadPointer 为什么不能直接传变量地址
它要求传入的是 *unsafe.Pointer，不是 &p 那种普通取址——如果你直接写 atomic.LoadPointer(&p)，Go 会报错：cannot take address of p（当 p 是未取址的 unsafe.Pointer 变量时）。根本原因是 Go 类型系统对 unsafe.Pointer 的地址操作做了限制，防止误用。
正确做法是先声明一个 unsafe.Pointer 类型的变量，再对其取址：
var p unsafe.Pointer ptr := atomic.LoadPointer(&p)
常见错误场景：想原子读一个结构体指针字段，比如 type Node struct{ next unsafe.Pointer }，然后写 atomic.LoadPointer(&n.next) ——这合法，因为 n.next 是字段，可取址；但若 n 是接口或 map 值，则 n.next 不可寻址，会编译失败。
LoadPointer 和 LoadUintptr 的区别在哪
二者语义不同：atomic.LoadPointer 专用于读取 unsafe.Pointer 类型值，而 atomic.LoadUintptr 读的是 uintptr。虽然底层都是按机器字长加载，但类型不互通——你不能用 LoadUintptr 去读一个 unsafe.Pointer 变量的地址，反之亦然。
典型误用：
- 把
unsafe.Pointer转成uintptr存进uint64字段，再用LoadUintptr读——这破坏了 GC 可达性，指针可能被回收 - 用
LoadPointer读一个uintptr类型变量——编译报错：类型不匹配
真正安全的转换路径只有一条：unsafe.Pointer → uintptr（仅在需要做算术时），且必须立刻转回 unsafe.Pointer，中间不能存为 uintptr 变量。
什么时候必须用 LoadPointer 而不是普通读
只有当你在无锁数据结构（如并发链表、跳表、无锁栈）中读取指针字段，并且该指针可能被其他 goroutine 同时更新时，才需要 atomic.LoadPointer。普通业务代码里，如果只是读一个全局配置指针、且从不修改，完全不需要原子操作。
关键判断点：
- 读操作和写操作（
atomic.StorePointer）是否跨 goroutine 发生 - 该指针是否指向堆上对象（栈上局部指针原子读没意义，还可能因逃逸分析失效）
- 是否依赖读操作的顺序性（比如先读
next，再读next.data，需保证看到一致状态）
注意：LoadPointer 本身不提供内存序之外的同步语义，它只是“原子读”，不代表后续的非原子访问（如解引用）自动受保护。
LoadPointer 的性能代价和替代方案
在 x86-64 上，atomic.LoadPointer 编译为单条 mov 指令，几乎没额外开销；但在 ARM64 上可能插入内存屏障（dmb ish），略重于普通读。不过比起加锁，仍是数量级优势。
容易忽略的坑：
- 不要为了“看起来线程安全”而滥用——对只读指针或初始化后不变的指针用原子读，纯属冗余
- 和
sync/atomic其他函数一样，它不检查 nil；如果存入的是 nil，LoadPointer返回的就是 nil，需自行判空 - 无法和
go:linkname或 CGO 混用，除非你清楚 runtime 对指针的追踪逻辑
真要极致性能且确定无并发写，可用 unsafe 手动绕过（不推荐），但一旦有写入，就必须配对使用 StorePointer，否则违反内存模型。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
