直接用 atomic.Int64 就安全，别手写 int64 + atomic.AddInt64 —— 后者在 ARM 或 32 位环境极易因内存不对齐触发 SIGBUS panic，而前者零值合法、自动处理对齐与内存序。
为什么 atomic.Int64 比裸 int64 + atomic.*Int64 函数更可靠
Go 编译器不保证 struct 中任意字段的地址对齐；如果 int64 前面有 [3]byte 这类非 8 字节对齐字段，它的地址可能偏移 3 字节，导致 atomic.AddInt64(&v, 1) 在某些平台直接崩溃。
-
atomic.Int64是值类型，声明即用：var counter atomic.Int64，零值为 0，无需初始化 - 嵌入 struct 时必须放在**第一个字段**，Go 保证 struct 首字段地址与 struct 地址一致，且首字段对齐即整体对齐
- 所有读写必须走它自己的方法：
counter.Load()、counter.Add(1)、counter.Store(100)，不能取地址传给旧式atomic.*Int64函数 - 方法内部已封装内存序（如
memory_order_relaxed），你不用操心atomic.LoadInt64和atomic.LoadInt64Acq的区别
需要「自增并返回旧值」怎么办
atomic.Int64 没有 IncAndReturnOld()，也不能用 Swap() —— 它不校验原值，会覆盖别人刚写入的新值，造成丢失更新。
- 正确做法是
Load+CompareAndSwap循环： func (c *atomic.Int64) IncAndGetOld() int64 { for { old := c.Load() if c.CompareAndSwap(old, old+1) { return old } } }- 高争用下可能重试多次，但比锁轻量；若业务能接受“返回新值”，直接
c.Add(1)最简 - 别写成
old := c.Load(); c.Store(old+1)—— 中间可能被其他 goroutine 修改，结果错
什么时候必须换 sync.Mutex
atomic 只保单个变量原子性，一旦逻辑跨步骤或跨字段，它就无能为力。
立即学习“go语言免费学习笔记（深入）”；
- 典型场景：计数器 + 最后更新时间戳 + 状态标志，三者需一起更新，
atomic不支持批量操作 - 结构体字段类型不支持原子：如
float64、map、自定义struct，只能用sync.Mutex或atomic.Value（后者要求类型固定） - 需要条件判断再修改：比如 “如果当前值 > 100 就重置为 0”，
atomic.CompareAndSwapInt64可实现，但代码易错且难读；用Mutex封装逻辑更直观 - 性能不是换锁的理由——100 万次自增，
atomic.AddInt64比Mutex.Lock/Unlock快 5–10 倍；换锁是为语义清晰，不是妥协
最容易被忽略的是嵌入 atomic.Int64 时的字段顺序，以及混用新旧 API 的隐性风险；哪怕只多一个 [1]byte 放在它前面，都可能让程序在某些设备上启动就 panic。
