不能直接用 int 类型做并发计数，因为 i++ 非原子，包含读取、加1、写回三步，多 goroutine 竞争会导致丢失更新；sync/atomic 提供 Add、Load、Store、CAS 等位宽明确的原子操作，Go 1.19+ 推荐使用 atomic.Int64 封装安全计数器。
为什么不能直接用 int 类型做并发计数
多个 goroutine 同时对一个普通 int 变量执行 ++ 或 --，结果大概率出错。因为 i++ 实际包含三步：读取、加 1、写回，中间可能被其他 goroutine 插入修改，导致丢失更新。这不是“偶尔出错”，而是只要并发足够高，就一定会复现。
sync/atomic 提供哪些原子操作函数
sync/atomic 对 int32、int64、uint32、uint64、uintptr 和指针类型提供原子读写与运算。最常用的是：
-
atomic.AddInt32(&i, 1)—— 原子加，返回新值 -
atomic.LoadInt32(&i)—— 原子读，避免编译器/CPU 重排序 -
atomic.StoreInt32(&i, 10)—— 原子写 -
atomic.CompareAndSwapInt32(&i, old, new)—— CAS，成功返回 true
注意：没有 atomic.AddInt，必须显式指定位宽（int32 或 int64），否则编译报错。
完整可运行的并发安全计数器示例
下面是一个基于 atomic.Int64（Go 1.19+ 推荐）的计数器封装，比裸用 atomic.AddInt64 更安全、更易复用：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
package main
import (
"fmt"
"sync"
"sync/atomic"
"time"
)
type Counter struct {
v atomic.Int64
}
func (c *Counter) Inc() int64 {
return c.v.Add(1)
}
func (c *Counter) Load() int64 {
return c.v.Load()
}
func main() {
var wg sync.WaitGroup
var counter Counter
for i := 0; i < 100; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for j := 0; j < 1000; j++ {
counter.Inc()
}
}()
}
wg.Wait()
fmt.Println("Final count:", counter.Load()) // 总是输出 100000
}
如果你还在用 Go atomic.AddInt64(&v, 1) 替代 c.v.Add(1)，原理相同，只是 API 更底层。
容易踩的坑和性能提示
原子操作不是万能锁替代品，用错反而引入隐蔽 bug：
- 别对局部变量或栈上变量取地址传给
atomic函数——地址无效，行为未定义 -
atomic.Load*和atomic.Store*是内存屏障，但不保证临界区逻辑原子性（比如“先读再算再写”仍需锁） - 频繁调用
atomic.LoadInt64本身开销极小，但若在 tight loop 中反复读同一变量，现代 CPU 通常会缓存该 cacheline，实际性能影响不大 - 如果计数器需要支持 reset、min/max 比较等复杂逻辑，
atomic不够用，应考虑sync.Mutex封装
真正要注意的，是位宽匹配和变量生命周期——这两点出错，程序不会 panic，但结果不可预测。
