atomic.AddInt64是并发计数的默认选择，因counter++非原子而atomic.AddInt64编译为单条CPU原子指令；必须用int64、变量地址稳定、所有读写都走atomic函数。
atomic.AddInt64 是并发计数的默认选择，别用 counter++
Go 里 counter++ 不是原子操作，它在汇编层拆成“读→加1→写”三步，中间可能被其他 goroutine 插入，结果必然错乱。而 atomic.AddInt64(&counter, 1) 编译为单条 CPU 原子指令（如 x86 的 LOCK XADD），硬件保证不可分割。
- 必须用
int64（或int32），别用int：平台相关，32 位系统上int可能是 32 位，int64才能保证自然对齐 - 变量地址必须稳定：推荐声明为包级变量，或用
new(int64)分配；别对局部变量取地址传给 atomic 函数，函数返回后地址就失效 - 所有读写都得走 atomic：一旦用了
atomic.AddInt64，就不能再写counter = 0或fmt.Println(counter)，否则破坏内存可见性
CompareAndSwapInt64 失败不是报错，是并发下的正常反馈
atomic.CompareAndSwapInt64(&x, old, new) 返回 false，只说明“此刻 x 的值不是 old”，不代表出问题。这是无锁编程的设计前提——你得自己决定是否重试、何时放弃。
- 典型场景是“只设一次”的状态标志，比如服务启动：
atomic.CompareAndSwapInt32(&status, 0, 1)成功才执行初始化逻辑 - 需要循环重试时，别裸写
for { ... }空转：高竞争下会吃满 CPU，建议加runtime.Gosched()让出时间片，或time.Sleep(1ns) - 别在循环里反复
var tmp int64 = atomic.LoadInt64(&x)再传地址——局部变量地址生命周期不够，行为未定义
想原子更新 map 或结构体？别硬套 atomic，改用 atomic.Value
sync/atomic 不支持结构体、map、slice、interface{} 等复合类型。试图对结构体字段调用 atomic.StoreInt64(&s.field, v) 不仅无效，还可能因字段未对齐 panic（尤其在 ARM 或开启 -gcflags="-d=checkptr" 时）。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
atomic.Value是唯一标准解法：它内部用读写锁 + 指针替换实现“整体替换”，安全但不提供原子增减 - 存和取必须类型一致：
config.Store(&Config{...})后，必须用config.Load().(*Config)，不能误转为*OtherStruct - 注意对象生命周期：
atomic.StorePointer和atomic.Value.Store都不会延长所存对象的存活时间；若对象只靠 atomic 引用，GC 可能在下次就回收它，导致后续Load解引用崩溃
LoadUint64 / StoreUint64 看似简单，但对齐不对就 panic
atomic.LoadUint64 要求操作的 uint64 变量必须落在 8 字节边界上。在 32 位 ARM 平台或启用严格检查时，未对齐访问会直接 panic：“invalid memory address or nil pointer dereference”。
立即学习“go语言免费学习笔记（深入）”；
- 结构体中放
uint64，务必放在首字段，或紧跟在其他 8 字节字段（如另一个uint64或uintptr）之后，避免被前面的byte、int32挤偏 - 验证对齐：用
unsafe.Alignof(x)看是否为 8，用unsafe.Offsetof(s.x)看字段偏移是否能被 8 整除 - 别用
unsafe.Offsetof手动算偏移去原子操作嵌套字段——极易出错，也绕不开对齐约束
