Go 并发计数器该用 atomic.AddInt64 还是 sync.Mutex
绝大多数场景下，优先用 atomic.AddInt64 —— 它快、轻量、无锁，且能正确保证计数器的原子性。只有当你需要「复合操作」（比如“读+判+写”）或计数器只是更大临界区的一部分时，才考虑 sync.Mutex。
哪些操作不能靠 atomic 完成，必须上 Mutex
atomic 只保证单个操作的原子性，不提供「多步逻辑的原子封装」。一旦涉及条件判断或依赖当前值做决策，atomic 就力不从心了。
- 「如果计数器小于 100 才加 1」——
atomic.LoadInt64+atomic.AddInt64中间可能被其他 goroutine 修改，结果不可靠 - 「加 1 后立刻记录日志并触发回调」—— 日志和回调不在原子范围内，
atomic无法保护 - 多个变量需同步更新（如
count和lastUpdated）——atomic无法跨变量协调
atomic 计数器的典型写法和易错点
别直接对变量做 ++ 或 +=；所有修改必须走 atomic 函数，且类型严格匹配（int64 是默认安全类型，int 在 32 位系统上非原子）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 初始化必须用
int64类型：var counter int64，不是int - 读取用
atomic.LoadInt64(&counter)，不是counter直接读（可能看到脏值） - 自增用
atomic.AddInt64(&counter, 1)，别写counter++（竞态！） - 避免在循环里高频调用
atomic.LoadInt64做轮询判断——可能掩盖设计问题，也影响性能
性能差多少？实测常见场景下的开销差异
在纯递增场景下，atomic.AddInt64 比 sync.Mutex 快 3–5 倍，内存占用更低，且不会因锁竞争导致 goroutine 阻塞。但这个差距只在高并发（数百 goroutine 以上）、高频（每秒百万次以上）计数时才明显。
立即学习“go语言免费学习笔记（深入）”；
- 低频计数（如每秒几百次）：两者感知不到差别，选哪个都行，但
atomic更简洁 - 争抢激烈时：
Mutex会排队、休眠、唤醒，带来调度开销；atomic是 CPU 级指令，无上下文切换 - 注意：
atomic不解决「可见性」以外的问题——比如你用atomic更新了计数，但没用atomic读，那读到的仍是旧值
真正容易被忽略的是：很多人以为用了 atomic 就万事大吉，结果在非原子路径上读写同一个变量，或者把 atomic 和普通赋值混用，反而埋下更隐蔽的竞态。
