atomic.LoadUint64 panic 的根本原因是传入了非法指针；必须确保指针指向合法、对齐且生命周期足够的内存，禁止使用局部变量地址、切片/map元素地址或未导出结构体字段地址。
atomic.LoadUint64 读取时 panic: invalid memory address
直接对未初始化或已释放的 *uint64 调用 atomic.LoadUint64 会触发 nil pointer dereference。Go 的 atomic 操作要求指针必须指向合法、对齐且生
命周期足够的内存地址。
- 确保变量声明为全局变量或通过
new(uint64)/&var显式取地址，不要传局部变量的地址（逃逸分析可能不保证安全） - 切片、map 中的元素地址不能直接用于 atomic —— 它们可能被重新分配，导致指针悬空
- 结构体字段需确保该字段是导出的、且结构体本身以指针形式持有（如
&s.field），但更稳妥的做法是把原子字段单独拎出来，避免误操作
用 atomic.StoreUint64 写入后，其他 goroutine 看不到新值
这不是 cache 一致性问题，而是缺少同步语义：atomic 写入本身是可见的，但若读端没用 atomic.LoadUint64，而是直接读变量（*p），就绕过了内存屏障，可能读到旧值或产生未定义行为。
- 读写必须配对使用同系列函数：写用
atomic.StoreUint64，读就必须用atomic.LoadUint64 - 禁止混用普通赋值和 atomic 操作 —— 即使类型匹配也不行，例如：
*p = 42和atomic.LoadUint64(p)是不兼容的 - 注意编译器不会报错，但行为不可靠；在 ARM64 或低负载机器上更容易复现“看不到更新”的现象
想原子地增减 int，但 atomic.AddInt32 不接受 *int
Go 的 atomic 包不提供泛型或接口适配，所有函数都严格按具体类型签名。int 是平台相关类型（32 位或 64 位），不能直接传给 atomic.AddInt32 或 atomic.AddInt64。
- 显式转换为确定宽度类型：把
int改成int32或int64，再取地址 - 如果必须用
int，优先选int64版本（x86_64 下int通常等价于int64），但需确认目标平台并加注释说明 - 不要用
unsafe.Pointer强转 —— 这破坏类型安全，且 Go 1.20+ 对某些 atomic 操作有额外对齐检查，可能 panic
var counter int64 atomic.AddInt64(&counter, 1) // ✅ 正确 // atomic.AddInt64((*int64)(unsafe.Pointer(&someInt)), 1) // ❌ 危险，不推荐
用 atomic.Value 存 interface{}，但多次 Store 后内存持续上涨
atomic.Value 内部使用无锁队列缓存旧值，供 GC 异步回收。若高频替换（比如每毫秒 Store 一次），旧值可能来不及被 GC 回收，表现为堆内存缓慢增长。
- 不是内存泄漏，但需警惕频率 —— 每秒几百次以内基本无感；超过 1k/s 建议评估是否真需要 atomic.Value
- 避免存储大对象（如长 slice、map）；可改用指针（
*HeavyStruct）减少拷贝和缓存体积 - 若只是开关或配置项，考虑用
atomic.Bool或atomic.Int64配合外部映射，比atomic.Value更轻量
