必须传指针，因atomic函数签名强制要求*int64等指针类型以直接操作内存地址；传值会编译失败，且变量须可寻址、8字节对齐，否则32位平台或ARM上可能panic。
直接用 atomic.AddInt64 或 atomic.LoadUint64 就能实现高性能原子计数，但前提是变量声明、传参方式、读写配对全部正确——错一处就可能静默丢数据或 panic。
atomic 函数为什么必须传指针？
所有 atomic 整数操作函数（如 atomic.AddInt64、atomic.CompareAndSwapUint64）签名都要求第一个参数是 *int64 或 *uint64。这不是设计选择，而是底层需要直接操作内存地址。
- 写成
atomic.AddInt64(counter, 1)会编译失败：报错cannot use counter (type int64) as type *int64 - 正确写法只有
atomic.AddInt64(&counter, 1)—— 必须显式取地址 - 局部变量（比如函数内
var x int64）取地址后传给atomic是合法的，但无实际并发意义；真正该保护的是包级变量或结构体字段 - 结构体字段如
s.count，要确保s本身可寻址（不能是 map 值、函数返回值等临时对象）
结构体里放 int64 字段，为什么运行时 panic？
atomic.LoadUint64 等 64 位操作在 ARM32、x86（32 位模式）或启用 -gcflags="-d=checkptr" 时，会检测地址是否 8 字节对齐。未对齐就直接 panic，不是竞态，是硬件访问违规。
- 常见陷阱：把
uint64字段塞在结构体中间，前面有bool、byte或string，导致编译器填充后偏移量不是 8 的倍数 - 验证方法：
unsafe.Offsetof(s.field) % 8 == 0必须为 true - 稳妥做法：把
uint64放结构体最前面；或用_ [7]byte手动对齐前导字段 - 更省心的做法：不嵌套，单独声明
var reqTotal uint64，避免结构体内存布局风险
CAS 失败了，是不是出错了？
atomic.CompareAndSwapInt64 返回 false 是并发下的常态，不是错误信号。它只说明“你读到的旧值，在你准备写入前已被别人改了”。忽略这个返回值，等于放弃并发安全。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：调一次
atomic.CompareAndSwapInt64(&x, old, new)就结束，结果高并发下更新丢失 - 标准写法是自旋重试：
for { old := atomic.LoadInt64(&x) if atomic.CompareAndSwapInt64(&x, old, old+1) { break } } - 别在循环里加
time.Sleep—— 它放大延迟、破坏调度公平性；runtime.Gosched()可选，但多数场景不需要 - 重试逻辑必须匹配业务语义：状态机切换通常要一直重试；用户已取消的操作，就得校验上下文后退出，不能盲目自旋
Load/Store 能替代 mutex 吗？
能，但仅限于「单变量纯读写」场景。一旦涉及多步判断、条件更新、或多个字段联动，atomic 就力不从心，反而掩盖真实竞态。
- 安全场景举例：
atomic.LoadUint64(&isRunning)判断服务开关、atomic.StoreUint64(&cfgVer, v)发布新配置快照 - 危险场景举例：
if atomic.LoadInt64(&count) —— 中间窗口期可能被其他 goroutine 插入修改，导致超限 - 这类逻辑必须用
sync.Mutex或atomic.CompareAndSwapInt64构建原子检查+更新，不能靠两次独立原子操作拼凑 - 更隐蔽的坑：用
atomic.Value存 map 后，再修改 map 内容 ——atomic.Value只保证 Store/Load 整个值的原子性，不保护内部可变对象
真正难的不是记住函数名，而是判断什么时候该用 atomic、什么时候必须退回到 sync.Mutex，以及怎么安排结构体字段才能让 atomic 不在 ARM 上突然崩溃。
