atomic.addint64必须传*int64指针，否则编译报错；变量须可寻址且8字节对齐，否则32位平台panic；atomic.value存值必须可比较，否则运行时崩溃。
atomic.AddInt64 必须传指针，否则编译失败；atomic.LoadInt64 在 32 位平台可能 panic；atomic.Value 存的值必须可比较——这些不是边界情况，而是日常踩坑高频点。
为什么 atomic.AddInt64(&x, 1) 编译报错？
函数签名强制要求 *int64，传值会直接被 Go 编译器拒绝：cannot use x (type int64) as type *int64 in argument to atomic.AddInt64。
更隐蔽的问题是“不可寻址”：
-
atomic.AddInt64(&42, 1)❌ 字面量无地址 -
atomic.AddInt64(&m["count"], 1)❌ map 值不可取地址 -
atomic.AddInt64(&getCounter(), 1)❌ 函数返回值临时对象不可取址
GOARCH=386），运行时仍可能 panic。
atomic.LoadInt64 在 32 位系统上为什么会 panic？
底层 CPU 指令要求 64 位原子操作的地址必须 8 字节对齐。Go 全局变量和堆分配对象通常满足，但栈上 struct 字段极易违规：
type BadCounter struct {
hits uint32 // 占 4 字节
total int64 // 偏移 = 4 → 未对齐！
}
解决方案：
- 把
int64字段挪到 struct 开头 - 前面补 padding：
_ [4]byte - 用显式对齐包装：
struct{ _ [0]uint64; v int64 } - 交叉编译时务必用
GOARCH=386 go run main.go实测
atomic.Value Store 时 panic: “store of uncomparable value” 怎么办？
atomic.Value 要求存入的值必须可比较（能用于 ==），否则运行时报错：sync/atomic: store of uncomparable value。
典型翻车场景：
- 含
map[string]int字段的 struct - 带
sync.Mutex或chan int的结构体 - 匿名 struct 中嵌套不可比较类型
- 只存纯数据：如
struct{ Host string; Port int } - 改用指针：
cfg.Store(&MyConfig{...})（指针本身可比较） - 序列化后存
json.RawMessage或[]byte
atomic.Value 不解决字段级原子性，它只保证整个值的替换是原子的。
atomic.AddUint64 能不能直接用来做“加完判断阈值”？
不能。atomic.AddUint64(&x, 1) 本身是原子的，但“加完立刻读取并判断”这整段逻辑不是原子的——中间可能被其他 goroutine 插入修改。
错误写法：
if atomic.AddUint64(&counter, 1) > 100 {
alert()
}
正确做法只有两种：
- 用
atomic.CompareAndSwapUint64循环重试（适合简单状态切换） - 该场景本质需要临界区保护，老实用
sync.Mutex或sync.RWMutex
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
