atomic不是银弹，仅在高频单计数器更新、开关状态读取等特定场景比锁快；误用会导致更慢、更难调试、更不可靠。
atomic 不是并发性能的银弹，它只在特定场景下比锁快——比如高频更新单个计数器、读取开关状态、或实现无锁初始化。用错地方反而会让程序更难调试、更慢、更不可靠。
什么时候该用 atomic.LoadInt64 而不是 sync.RWMutex.RLock()
当你只需要一次、无依赖、不参与条件分支的整数读取时，atomic.LoadInt64 才真正轻量。
- 适用：暴露 Prometheus 指标（如
http_requests_total）、读取服务运行标志isRunning、获取序列号生成器当前值 - 不适用：读完
counter就去查cache[uid]——atomic.LoadInt64不保证这两个访问之间的顺序 - 不适用：“如果余额 > 100 才扣款”这类逻辑 —— 这需要临界区，必须用
sync.Mutex或循环重试的atomic.CompareAndSwapInt64
atomic.CompareAndSwapUint64 必须循环重试
返回 false 是常态，不是错误；它只表示“值已被别人改了”，不是失败信号。
- 正确写法是显式
for循环：for { old := atomic.LoadUint64(&counter) if atomic.CompareAndSwapUint64(&counter, old, old+1) { break } } - 错误写法：
atomic.CompareAndSwapUint64(&counter, 1, 2)—— 一次调用就放弃，更新必然丢失 - 别加
time.Sleep退避：Go 调度器不保证唤醒精度，反而放大延迟 - 若失败意味着业务条件已变（如订单已取消），就不能盲目重试，得重新校验上下文
atomic.Value 存 struct 是危险操作
atomic.Value.Store() 存的是副本，Load() 返回的也是新副本，原始 struct 修改后，副本不会同步更新。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 典型误用：
var cfg atomic.Value cfg.Store(&Config{Timeout: 30}) c := cfg.Load().(*Config) c.Timeout = 60 // 修改的是副本，不影响下次 Load() - 安全做法：只存指针（
*Config）、小接口（io.Reader）或函数（func()） - 字段间无约束关系时，才考虑拆成多个
atomic.Int64；否则优先用sync.RWMutex保护整个 struct
32 位系统上 int64 原子操作可能 panic
未对齐的 int64 在 32 位平台会触发 runtime panic，这不是 bug，而是硬件限制。
立即学习“go语言免费学习笔记（深入）”；
- 规避方式：把
int64放在结构体首字段（Go 编译器保证首字段对齐） - 或统一用
atomic.Value包一层，它内部处理了对齐问题 - 线上服务若仍需兼容 32 位环境（如某些嵌入式微服务），务必在 CI 中启用
GOARCH=386测试
atomic.AddInt64 多快，而是你有没有把高竞争点从全局锁里解放出来——比如把一个大 map 拆成 64 个分片，每个配独立 sync.Mutex，往往比全换成 atomic 更有效。原子操作只是工具箱里的一把螺丝刀，拧错地方，再亮也白搭。 
