atomic.addint64必须传指针，因函数签名要求*int64以直接操作内存地址；传值编译报错，且变量须可寻址、8字节对齐，否则32位平台可能panic。
为什么 atomic.AddInt64(&x, 1) 必须传指针？
因为 atomic.AddInt64 函数签名强制要求 *int64 类型参数——它要直接操作内存地址，不是拷贝值。传值会编译报错：cannot use x (type int64) as type *int64 in argument to atomic.AddInt64。
- 变量必须可寻址：不能是字面量（如
atomic.AddInt64(&42, 1)）、不能是 map 值（如m["count"]）、不能是函数返回值（如&getCounter()） - 结构体字段需确保实例本身可寻址：用变量而非临时 struct 字面量；推荐把原子字段提为包级变量或嵌入到可寻址对象中
- 局部变量一般没问题，但若逃逸到堆上且未对齐（尤其在 32 位平台），64 位操作可能 panic
int64 在 32 位系统上为什么会 panic？
atomic.LoadInt64 等 64 位操作要求变量地址 8 字节对齐；而 32 位平台（如 GOARCH=386 或 armv7）不保证栈上局部变量或 struct 字段天然对齐，运行时检测失败即触发 panic: runtime error: invalid memory address or nil pointer dereference（底层是 SIGBUS）。
- 最稳妥解法：声明为包级变量（全局变量通常天然对齐）
- 若必须放结构体里，用对齐技巧：
struct{ _ [0]uint64; v int64 }，或 Go 1.17+ 起可用//go:align 64注释 - 交叉编译时务必测试目标平台：
GOARCH=386 go run main.go - 替代方案：统一用
int32+atomic.AddInt32，牺牲范围换兼容性
Load/Store 能代替 mutex 吗？
能，但只在「单字段纯读写」场景下安全。它们不提供临界区保护，也不阻塞，只保证单次内存操作不可分割。
- ✅ 安全场景：计数器累加（
atomic.AddUint64(&counter, 1)）、状态标志切换（atomic.StoreUint32(&state, 1)）、配置版本快照（atomic.StoreUint64(&cfgVer, newVer)） - ❌ 不行场景：需要“读-判断-写”逻辑（如“如果 count atomic.CompareAndSwapUint64 循环重试）、多个字段需同步更新（如 user.name 和 user.age）、写操作含副作用（如发消息、改文件）
- ⚠️ 注意：
atomic.LoadUint64读到的值一定是最新的，但不代表“此刻仍有效”——它不锁住后续逻辑，业务层仍需自行处理竞态语义
想原子操作 float 或 struct 怎么办？
sync/atomic 不支持 float32/float64 或任意结构体的直接原子操作。官方明确不提供浮点原子函数，也没有字段级原子能力。
- 浮点数：转成
uint64用math.Float64bits/math.Float64frombits编解码后操作，例如：atomic.StoreUint64(&bits, math.Float64bits(3.14)) - 结构体或任意类型：用
atomic.Value，它支持Store和Load任意可赋值类型（包括指针、map、struct），但注意它内部是 copy-on-write，大对象有开销 - 别试图对 struct 字段单独原子操作：即使字段类型合法（如 int64），字段地址也可能不对齐，直接调用
atomic.LoadInt64(&s.field)在某些平台会 panic
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
