atomic.CompareAndSwapInt64 必须配合 for 循环自旋重试，因 CAS 不保证一次成功；需每次循环先 Load 再计算新值后尝试更新；结构体字段不可直接 CAS，应拆为顶层变量或封装原子结构体；浮点数等非整型不支持原生 CAS；DB 乐观锁与内存 CAS 机制不同，需手动双写同步；高冲突场景应分片或改用互斥锁。
atomic.CompareAndSwapInt64 必须配合 for 循环重试
CAS 本身不保证一次成功，atomic.CompareAndSwapInt64 返回 false 表示值已被其他 goroutine 修改，此时必须重读再试。单次 if 判断会直接丢弃更新逻辑，导致数据丢失。
常见错误写法：
if atomic.CompareAndSwapInt64(&counter, old, old+1) { /* 成功 */ } else { /* 不做任何事 → 更新静默失败 */ }正确模式是自旋重试：
- 每次循环先用
atomic.LoadInt64(&counter)获取最新值 - 基于当前值计算新值（如加 1、校验阈值等）
- 调用
atomic.CompareAndSwapInt64尝试更新 - 成功则
break；失败则继续下一轮
注意：不能省略 LoadInt64 直接复用旧局部变量——中间状态可能已变。
立即学习“go语言免费学习笔记（深入）”；
结构体字段无法直接 CAS，需拆出顶层变量
atomic.CompareAndSwapInt64 只接受 *int64 类型指针，而结构体字段地址（如 &s.version）在某些布局下可能非法（比如字段未对齐或被编译器优化掉）。强行取址容易 panic 或行为未定义。
安全做法是把需要 CAS 的状态字段单独拎出来：
- 用独立的顶层变量（如
var productVersion int64） - 或封装为带原子字段的结构体（如
type ProductState struct { version int64 }，再用&state.version） - 避免对
struct{ version int64 }中的version直接取址传入 CAS
浮点数、字符串、map 等类型不支持原生 CAS，强行转 uint64 有字节序和内存对齐风险，生产环境应规避。
数据库乐观锁与内存 CAS 是两套机制，别混用
GORM 的 Version 字段乐观锁靠 SQL 的 WHERE id = ? AND version = ? 实现，失败时 RowsAffected == 0；而 atomic.CompareAndSwapInt64 是纯内存操作，不涉及 IO 或事务。
两者不可互相替代，但可协同：
- 读 DB 后，用
atomic.LoadUint64(&obj.version)拿到当前版本号，拼进 SQL 的WHERE条件 - DB 更新成功后，再用
atomic.StoreUint64(&obj.version, newVer)同步内存状态 - 切勿在 GORM 回调里对 struct 字段做 CAS——DB 提交后，内存 struct 已过期，CAS 失去意义
如果业务要求“内存状态 + DB 状态强一致”，必须手动双写版本号，不能依赖 ORM 自动同步。
高冲突场景下自旋会吃满 CPU，得设兜底策略
当多个 goroutine 频繁竞争同一变量（如每秒上千次 CAS 失败），for 循环会持续占用 CPU，出现明显性能抖动。这不是 bug，而是 CAS 的固有限制。
应对方式不是硬扛，而是分层处理：
- 冲突低频（如库存扣减、任务状态流转）：放心用 CAS + 自旋
- 冲突中频（如计数器聚合）：考虑分片（sharding），按 key hash 到不同原子变量
- 冲突高频（如热点账户余额）：退回到
sync.Mutex或分布式锁，别为“无锁”牺牲稳定性
另外，atomic.CompareAndSwapInt64 不解决 ABA 问题——值从 A→B→A，CAS 会误判成功。若业务敏感（如资源池回收），需引入版本号或序列号字段。
