atomic.addint64比锁更合适做id生成器，因其编译为单条lock xadd指令，硬件级原子性、无调度开销与死锁风险；而mutex在高并发下易成性能瓶颈并引发panic或id重复。
为什么 atomic.AddInt64 比锁更合适做ID生成器
因为自增ID本质是单点、高频、无分支的计数操作，atomic.AddInt64 在x86-64上编译为一条 lock xadd 指令，硬件级保证原子性，没有锁的调度开销和潜在死锁风险。用 sync.Mutex 反而成了性能瓶颈，尤其在高并发场景下，goroutine排队阻塞明显。
常见错误现象：panic: sync: unlock of unlocked mutex 或 ID重复（误用非原子读写）；或者压测时QPS卡在几千就上不去——大概率是锁争用。
- 必须用
int64类型（atomic包不支持int直接原子操作，32位系统上int可能是32位，会出错） - 初始值建议从
1开始，避免后续逻辑把0当作未初始化 - 不要对原子变量做取地址传参（如
&counter），atomic函数接收的是指针，但你传的必须是变量本身地址，不是中间变量的地址
如何安全地封装成可复用的 IDGen 结构体
直接裸用 atomic.AddInt64 容易漏掉初始化或误复用全局变量。封装结构体能明确生命周期、支持多实例隔离（比如不同业务线要独立ID空间），也方便加监控字段（如当前最大值、调用次数）。
使用场景：微服务中每个服务实例需要本地单调递增ID（非全局唯一，但本机不重复），或作为数据库代理层的临时ID占位符。
立即学习“go语言免费学习笔记（深入）”；
- 字段必须导出且类型为
int64，例如counter int64；不可用uint64，因为atomic包没提供Uint64增量函数 - 构造函数里用
atomic.StoreInt64(&g.counter, start)初始化，别用普通赋值（普通赋值不保证其他goroutine立即可见） - 方法签名建议返回
int64，而非string或fmt.Sprintf，字符串转换留到业务层，避免在热点路径做内存分配
示例关键片段：
type IDGen struct {
counter int64
}
func NewIDGen(start int64) *IDGen {
g := &IDGen{}
atomic.StoreInt64(&g.counter, start)
return g
}
func (g *IDGen) Next() int64 {
return atomic.AddInt64(&g.counter, 1)
}
atomic.LoadInt64 和 atomic.AddInt64 混用时的典型陷阱
想“先看当前值，再决定是否加”，这种读-改-写模式不能靠两次原子操作拼出来——中间可能被其他goroutine插队修改，导致逻辑错乱。比如判断是否超限后才 Add，结果判断完瞬间别人已加到上限，你又越界了。
性能影响：看似只是多一次 Load，但实际破坏了CPU缓存行局部性，频繁读写同一地址会引发 false sharing（尤其在多核NUMA机器上），反而比单纯 Add 慢20%+。
- 绝对不要写
if atomic.LoadInt64(&x) 这类代码 - 如果真要带条件自增，得用
atomic.CompareAndSwapInt64循环重试，但ID生成器通常不需要——直接加完再检查返回值是否越界更简单可靠 - 调试时用
atomic.LoadInt64查当前值没问题，但生产逻辑里避免把它嵌入决策链
跨进程/重启后ID不连续怎么办
原子操作只管本进程内存，不解决持久化或分布式问题。如果你发现服务重启后ID从1开始，或两个实例生成了相同ID，这不是原子操作的问题，而是设计边界没划清。
使用场景限定：这个生成器只适用于「单实例、短生命周期、不要求全局唯一或严格连续」的场合，比如日志流水号、临时会话ID、内存缓存key前缀。
- 需要重启不丢号？得配合本地文件 +
atomic内存映射，或启动时从磁盘读取并StoreInt64初始化 - 需要多实例不冲突？要么加中心节点（Redis自增），要么用时间戳+机器码+原子计数拼接（Snowflake变种），但那就超出纯
atomic能力范围了 - 别试图用
unsafe.Pointer把原子变量映射到mmap文件——Go runtime不保证这种用法的内存模型安全性，行为未定义
真正容易被忽略的是：很多人以为“用了atomic就天然支持分布式”，其实它连单机多进程都不支持。进程隔离是操作系统的基本前提，atomic 操作从来只在自己的虚拟地址空间里生效。
