atomic.LoadInt64不能直接读struct字段，因字段可能未内存对齐；正确做法是将需原子操作的字段单独封装为导出字段并确保不被编译器重排。
atomic.LoadInt64 为什么不能直接读 struct 字段
Go 的 atomic 函数只接受指针类型，且要求目标内存必须是“对齐的、可原子访问的”基础类型（如 int32、int64、uint64、unsafe.Pointer）。如果你试图对 struct 中某个 int64 字段直接取地址并传给 atomic.LoadInt64，编译会通过，但运行时可能 panic 或产生未定义行为——因为该字段未必在内存中独立对齐（尤其当它前面有其他字段时）。
正确做法是：把需要原子访问的字段单独拎出来，作为顶层变量或嵌入到专用结构体中，并确保它不被编译器重排。更稳妥的是用 sync/atomic 提供的专用类型，比如：
type Counter struct {
v int64
}
func (c *Counter) Add(n int64) int64 {
return atomic.AddInt64(&c.v, n)
}
func (c *Counter) Load() int64 {
return atomic.LoadInt64(&c.v)
}
- 字段
v必须是导出的（首字母大写），否则无法取地址（尽管这里没导出也行，但为清晰起见建议导出） - 不要在多个 goroutine 中混用
atomic操作和普通赋值（如c.v = 10），这会破坏原子性语义 - struct 内部字段若需并发安全，优先考虑封装 + 原子操作，而非裸露字段
什么时候该用 atomic 而不是 mutex
atomic 是无锁的，开销极小，但能力有限；mutex 更重，但能保护任意复杂逻辑。选 atomic 的前提是：你只做「单个变量的简单读写/修改」，且该操作本身是 CPU 支持的原子指令（如 x86 的 XADD、ARM 的 LDXR/STXR）。
典型适用场景包括：
- 计数器（请求量、错误数、活跃连接数）
- 状态标志（
isRunning、isClosed，用int32模拟 bool） - 指针替换（如配置热更新：
atomic.StorePointer(&config, unsafe.Pointer(newCfg))） - 实现自旋锁或轻量级信号量（配合
atomic.CompareAndSwap）
反例：你要「先读 A，再根据 A 的值决定是否更新 B 和 C」——这已超出原子操作能力，必须用 sync.Mutex 或 sync.RWMutex。
