counter++在多goroutine下必然不可靠，因其被拆为读取→加1→写回三步，中间可被抢占导致覆盖；必须用atomic.addint64等原子操作，且需满足类型、对齐、初始化三前提。
为什么不能直接用 counter++？——竞态不是“可能出错”，是“必然不可靠”
多个 goroutine 同时执行 counter++，结果几乎一定小于预期值，且每次运行都不一样。这不是概率问题，而是因为该操作在底层拆成三步：读取 → 加 1 → 写回，中间任何一步都可能被其他 goroutine 打断并覆盖。
- 常见错误现象：
go run -race直接报Data race: Read at ... by goroutine N / Previous write at ... by goroutine M - 更隐蔽的问题：32 位系统上对
int或未对齐的int64做原子操作，会 panic：panic: unaligned 64-bit atomic operation - 别指望“我只读不写就安全”——只要有一个 goroutine 在写，所有读也必须用
atomic.LoadInt64，否则可能读到撕裂值（比如高位是旧值、低位是新值）
atomic.AddInt64 怎么用才不出错？——类型、对齐、初始化三件套缺一不可
它不是给任意 int64 变量加 1 的万能函数，而是一套有严格前提的协作机制。
- 变量必须是
int64类型（不能是int），且地址需自然对齐（% 8 == 0）：全局变量默认满足；结构体中建议把int64字段放在首位 - 初始化必须用
atomic.StoreInt64(&counter, 0)，而不是counter = 0——后者不是原子写，其他 goroutine 可能读到未初始化的垃圾值 - 所有读写必须统一走 atomic 函数：
atomic.LoadInt64、atomic.AddInt64、atomic.SwapInt64，禁止混用普通赋值或自增 -
atomic.AddInt64(&c, 1)返回新值；atomic.AddInt64(&c, -1)可减，但业务上是否允许负数，得由你控制，原子包不校验语义
var counter int64
func init() {
atomic.StoreInt64(&counter, 0) // 必须这样初始化
}
func Inc() { atomic.AddInt64(&counter, 1) }
func Get() int64 { return atomic.LoadInt64(&counter) }
什么时候该换 sync.Mutex？——别硬套原子操作去干它不擅长的事
atomic 只保单次操作原子性，一旦涉及“先读再判断再改”，它就失效了。这时候强行用 CompareAndSwapInt64 循环重试，代码难懂、性能还可能更差。
- 典型踩坑场景：
if atomic.LoadInt64(&c) —— 两次原子调用之间，<code>c可能已被别人改过，条件彻底失效 - 适合用锁的场景：带上限的计数器、需防负数、要和日志/通知联动、或后续逻辑依赖该值变化（比如“达到阈值就关闭连接”）
- 性能影响没你想的那么大：除非每秒百万级计数，否则
sync.Mutex的开销远小于你花在调试竞态上的时间 - 简单封装示例：
type Counter struct { mu sync.Mutex n int64 }，Inc()和Value()方法里加锁即可，清晰、可靠、易扩展
高并发下还要注意什么？——对齐、自旋、内存序这些细节真会炸
高频调用 atomic.AddInt64 没问题，但若叠加不当模式，反而引发新问题。
- 别在 for 循环里反复
LoadInt64等条件满足再AddInt64——这是自旋，空耗 CPU，还可能饿死其他 goroutine - 如果计数器要参与同步逻辑（比如“值变到 5 就发信号”），别只依赖
Load/Add的默认内存序；必要时配合atomic.StoreInt64显式建立 happens-before 关系 - 跨包导出的计数器变量（如
var Hits int64），必须确保初始化和访问都走 atomic，否则其他包直接读Hits就是未同步行为
atomic.StoreInt64——很多人写了 var counter int64 就以为万事大吉，结果上线后偶发错，查半天才发现是未定义行为。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
