sync/atomic整数操作必须用指针传参，因其函数需直接读写内存地址而非拷贝值；传值会编译报错，正确写法是取地址如atomic.addint64(&count, 1)。
为什么 sync/atomic 的整数操作必须用指针传参
因为所有 atomic.AddInt64、atomic.LoadUint32 这类函数签名都要求传入 *int64、*uint32 —— 它们要直接读写内存地址，不是拷贝值。传值进去会编译报错：cannot use xxx (type int64) as type *int64 in argument to atomic.AddInt64。
常见错误是把变量名直接塞进去，比如：
var count int64 = 0 atomic.AddInt64(count, 1) // ❌ 编译失败正确做法只有这一种：
- 声明变量时就用可寻址的变量（不能是字面量或临时计算结果）
- 调用时加取地址符：
atomic.AddInt64(&count, 1) - 如果变量在结构体里，确保结构体实例本身可寻址（比如是变量而非 map 值或函数返回值）
atomic.LoadUint64 和 atomic.StoreUint64 能替代 mutex 吗
能，但只在「纯读写标量」场景下安全。它们不提供临界区保护，也不阻塞，只是保证单次读/写操作原子——也就是说，不会读到“半个更新”，也不会写一半被中断。
立即学习“go语言免费学习笔记（深入）”；
典型适用场景：
- 状态标志切换（如
isRunningbool 类型转成uint32用atomic.LoadUint32判断） - 计数器累加（
atomic.AddUint64(&counter, 1)） - 只读配置快照（先
atomic.StoreUint64(&cfgVer, newVer)，其他 goroutine 用atomic.LoadUint64读）
不能替代 mutex 的情况：
- 需要同时读+写+判断（比如“如果 count atomic.CompareAndSwapUint64 或锁
- 操作涉及多个字段（如 user.name 和 user.age 需同步更新）——原子包不支持多字段事务
- 写操作包含非原子逻辑（比如先改字段再发消息）——原子操作只管内存，不管业务语义
64 位原子操作在 32 位系统上为何可能 panic
go 要求 64 位原子操作（如 atomic.LoadInt64）的变量地址必须是 8 字节对齐，而 32 位平台（如 armv7、386）默认不保证 Struct 字段或栈变量的严格对齐，运行时检测到未对齐就会 panic：panic: runtime Error: invalid memory address or nil pointer dereference（实际底层是 signal SIGBUS）。
解决方法很具体：
- 用
struct{ _ [0]uint64; v int64 }强制对齐（Go 1.17+ 推荐用align64标签） - 全局变量或堆分配变量通常天然对齐，优先把原子变量提成包级变量或字段
- 交叉编译时注意目标平台：
GOARCH=386 go build下务必测试 64 位原子操作 - 更稳妥的做法：在 32 位环境统一用
atomic.Value包装指针，或直接上sync.Mutex
用 atomic.Value 存 Interface{} 时最容易漏掉什么
它只保证“存”和“取”操作本身原子，但不保证内部值的线程安全。比如存一个 map[String]int，多个 goroutine 同时 Load().(map[string]int 后直接写这个 map，依然会 panic：fatal error: concurrent map writes。
真正安全的用法只有两种：
典型反模式：
var config atomic.Value config.Store(map[string]int{"a": 1}) // ❌ 后续并发修改 map 会崩溃 v := config.Load().(map[string]int v["b"] = 2 // panic!正确写法是每次更新都新建整个 map：
newMap := make(map[string]int for k, v := range oldMap { newMap[k] = v } newMap["b"] = 2 config.Store(newMap) // ✅对大对象来说，频繁复制成本高，这时候该换 sync.RWMutex 了——原子包不是万能胶，它只解决“换引用”这一步。