atomic.AddInt64是最常用且安全的原子递增选择，因其底层调用CPU原语实现无锁操作，避免竞态；需传入int64指针、确保内存对齐，不适用于复合逻辑，复杂场景应改用sync.Mutex。
为什么 atomic.AddInt64 是最常用且安全的选择
Go 标准库的 atomic 包提供了一组真正无锁的原子操作，atomic.AddInt64 就是其中最直接满足“数据递增”需求的函数。它底层调用 CPU 的 XADD（x86）或 LDADD（ARM）等原语，不依赖 OS 互斥量，也不触发 goroutine 阻塞。
常见错误是试图用 ++ 或 += 替代——这些操作在 Go 中不是原子的，即使变量是全局或指针传递，多 goroutine 并发读写仍会导致竞态（go run -race 会报 race detected）。
-
atomic.AddInt64要求操作对象是指向int64的指针，不能对普通变量或int直接调用 - 必须确保该内存地址生命周期足够长（比如全局变量、结构体字段，或通过
new(int64)分配） - 如果只是计数器，优先用
int64；避免用int因为其宽度平台相关，atomic不提供atomic.AddInt
var counter int64 // 正确：每次 +1 atomic.AddInt64(&counter, 1) // 错误：非原子操作 counter++ // ⚠️ 竞态风险
如何在结构体中安全嵌入原子递增字段
实际项目中计数器常作为结构体字段存在，但要注意字段对齐和内存布局——atomic 操作要求目标地址自然对齐（如 int64 需 8 字节对齐）。Go 编译器通常能自动对齐，但若字段前有小尺寸成员（如 bool、int8），可能破坏对齐。
- 把
int64字段放在结构体开头，或用_ padding [7]byte手动对齐（极少需要） - 不要用
unsafe.Offsetof计算偏移后取地址传给atomic——除非你明确控制内存布局且测试覆盖充分 - 推荐方式：直接导出字段并加注释说明“此字段需原子访问”，避免封装 getter/setter 带来不必要的间接调用
type Stats struct {
Hits int64 `json:"hits"` // ✅ 放开头，对齐有保障
Name string
}
s := &Stats{}
atomic.AddInt64(&s.Hits, 1) // 安全
什么时候不该用 atomic 而该换 sync.Mutex
原子操作只适用于简单整数增减、位运算、指针交换等有限场景。一旦涉及“读-改-写”复合逻辑（比如“如果值小于 100 才加 1”），atomic 无法保证整体原子性，强行用 atomic.Load/Store 循环重试（CAS loop）容易写出 bug 或性能反模式。
立即学习“go语言免费学习笔记（深入）”；
-
atomic.CompareAndSwapInt64可用于简单条件更新，但失败时需手动重试，易漏循环终止条件 - 若递增逻辑依赖其他字段状态（如“用户登录次数 ≤ 3 才允许再登录”），必须用
sync.Mutex或sync.RWMutex保护整个临界区 - 高竞争下（每秒百万级 CAS 失败），
atomic自旋开销可能高于锁的系统调用开销，此时Mutex反而更稳
注意 atomic 不提供顺序保证，必要时加 atomic.Store/Load 配套
atomic.AddInt64 默认提供 seqcst（sequential consistency）内存序，多数场景够用。但如果你在递增前后还操作其他非原子变量（比如更新一个 map 或切片），不能假设它们会按代码顺序被其他 goroutine 观察到。
- 例如：先
atomic.AddInt64(&counter, 1)，再log.Printf("count=%d", counter)—— 日志里看到的counter值可能滞后 - 正确做法：所有共享状态读写都走
atomic，或统一用sync.Mutex，别混用 - 若必须混合，用
atomic.StorePointer/atomic.LoadPointer显式同步指针引用，而非依赖执行顺序
无锁不是银弹，它把复杂性从锁争用转移到了内存模型理解和并发逻辑验证上。写完记得跑 go test -race，比想清楚更重要。
