atomic.loaduint64总是返回0的根本原因是写操作未走原子路径，必须全部使用atomic.storeuint64等配对函数，禁止裸赋值或非原子修改，且需确保uint64变量8字节对齐、类型严格匹配。
atomic.LoadUint64 总是返回 0？不是函数坏了，是你写没走原子路径。
写操作必须配对使用原子函数，禁止裸赋值
常见错误是：counter = 100 或 counter++ 直接修改 uint64 变量，然后用 atomic.LoadUint64(&counter) 读——这必然看到旧值甚至 0。
-
atomic.Load*只读“那一刻的内存快照”，但非原子写入不保证被其他 goroutine 的原子读观察到 - 所有写必须用
atomic.StoreUint64、atomic.AddUint64等原子函数，不能混用 - 类型必须严格匹配：对
int32变量调atomic.LoadUint64会 panic 或读错内存
uint64 字段必须自然对齐，否则 ARM 平台直接崩溃
Go 要求 uint64（以及 int64）变量地址是 8 字节对齐的，否则在 32 位 ARM 或启用 -gcflags="-d=checkptr" 时 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 结构体中把
uint64放在首字段最安全；若前面有byte、bool、int32，可能把它“挤偏”导致未对齐 - 用
unsafe.Alignof(x)和unsafe.Offsetof(s.x)验证余数是否为 0 - 别用
unsafe.Offsetof手动算嵌套字段偏移去原子操作——极易出错，优先单拎出来声明
CAS 必须写循环，失败不是异常而是常态
atomic.CompareAndSwapUint64 返回 bool，成功才 true。它不 panic、不报错，只告诉你“这次没换上”。
- 典型误用：
atomic.CompareAndSwapUint64(&counter, old, old+1)后不检查返回值，也不重试 - 正确模式是 CAS loop：读 → 算 → 尝试 → 失败则重读，直到成功
- 高竞争下别无脑自旋；必要时加
runtime.Gosched()让出或指数退避
atomic.Value 不是万能 map 安全器，写入后内容不可再改
atomic.Value 适合写少读多、且写入对象本身不可变的场景，比如配置热更新。但它不保护你塞进去的对象内部。
- 错误写法：
v.Store(m); m["key"] = "new"——m是 map，Store 后仍可被并发修改，线程不安全 - 正确写法：
v.Store(map[string]int{"a": 1})，每次 Store 全新副本 - 首次
Load()前必须Store()初始化，否则 panic：sync/atomic: store of nil value into Value
atomic.Load* 默认是 Relaxed 模型，不提供同步屏障；而未对齐的 int64 字段，在某些平台不是竞态，是直接 SIGBUS 崩溃。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
