atomic 包适用于单指令可完成且不依赖读-改-写以外逻辑的场景，如计数器、标志位；滥用易致竞态，结构体字段需用 atomic.Value 封装，int64 在32位系统须8字节对齐，Load/Store 需配合内存序保证可见性，atomic.Value 不可存含 mutex 的结构体，高频写慎用，复合状态变更优先选 sync.Mutex。
Go 的 atomic 包不是“用来替代 mutex”的万能工具，而是为特定场景（如计数器、标志位、指针交换）提供无锁、低开销的原子操作。滥用它反而会引入竞态或难以调试的问题。
什么时候该用 atomic 而不是 sync.Mutex
核心判断标准：操作是否满足「单个机器指令可完成」且「不依赖读-改-写以外的逻辑」。
-
atomic.AddInt64(&counter, 1)安全——加法是原子的，不需要先读再判再写 -
if counter == 0 { counter = 1 }不安全——必须用sync.Mutex或atomic.CompareAndSwapInt64，否则存在竞态窗口 - 结构体字段不能直接原子操作，除非用
atomic.Value封装整个值（注意：Store/Load是深拷贝语义） - 32 位系统上对
int64使用atomic必须确保地址 8 字节对齐，否则 panic；Go 1.17+ 在非对齐时自动 fallback 到 mutex，但性能下降明显
atomic.LoadUint64 和 atomic.StoreUint64 的典型误用
这两个函数常被当成“线程安全的 getter/setter”，但它们只保证单次读/写原子性，不提供顺序保证。在没有同步原语配合时，编译器和 CPU 可能重排指令，导致看到过期值或部分更新的中间状态。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：搭配
atomic.Load/Store使用atomic.MemoryBarrier()（已废弃）或更推荐的sync/atomic内置内存序（如atomic.LoadAcquire/atomic.StoreRelease） - 常见陷阱：在 goroutine 启动前用
StoreUint64写标志位，但主 goroutine 没用StoreRelease，子 goroutine 用LoadAcquire读，否则无法保证可见性 - 简单场景下，用
atomic.Bool（Go 1.19+）比uint32+atomic.CompareAndSwapUint32更清晰、不易出错
为什么 atomic.Value 不能存含 mutex 的结构体
atomic.Value 要求存储的值是可复制的（即 Copyable），而 sync.Mutex 内部含不可复制字段（如 state 和 sema），直接 Store 会导致 panic：“sync.Mutex is not copyable”。
立即学习“go语言免费学习笔记（深入）”；
- 错误示例：
v.Store(struct{ mu sync.Mutex; data int }{})—— 编译期不报错，运行时 panic - 正确做法：把 mutex 放在结构体外，或改用
sync.RWMutex+ 普通变量；若必须原子替换整个配置对象，确保其字段全是基本类型或指针（如*Config） -
atomic.Value的Store和Load有额外分配开销，高频写场景慎用；读多写少（如配置热更新）才合适
真正难的不是调用哪个 atomic 函数，而是判断「这段逻辑是否真的能被拆成原子步骤」——多数业务代码里的“复合状态变更”，还是老实用 sync.Mutex 更稳妥。
