atomic.AddInt64替代mutex.Lock时，int64必须显式声明并内存对齐，不可用int；struct中应将int64置于开头或手动校验对齐；状态标志宜用uint32配合CAS；指针热更新需原子交换且结构体只读；CAS循环须限重试次数；atomic操作不自动保证happens-before，需成对使用Load/Store。
热路径里用 atomic.AddInt64 替代 mutex.Lock() 时，int64 必须显式声明且对齐
Go 的 atomic 操作不接受 int 或 uint 类型——它们在 32 位系统上可能只有 32 位宽，无法保证 64 位原子性。热路径中若用 int 声明计数器再传给 atomic.AddInt64，会触发 panic 或未定义行为。
- 必须写成
var counter int64，不能是var counter int - 字段在 struct 中需注意内存对齐：如果前面有
byte字段，int64可能被填充错位，导致 atomic 操作失败；建议把int64放 struct 开头，或用//go:notinheap+ 手动对齐校验 - 所有读写都得走
atomic.LoadInt64/atomic.StoreInt64，混用普通赋值（如counter = 100）会引入竞态
状态标志（running/done）别用 bool，用 uint32 + CompareAndSwapUint32 实现单次切换
Go 标准库直到 1.19 才加入 atomic.Bool，但它是封装在 atomic.Value 里的间接类型，不是底层原子指令；热路径应直奔原语。直接用 bool 字段配 atomic.StoreBool 是错的——该函数不存在。
- 声明为
var done uint32，0 表示 false，1 表示 true - 启动逻辑用
atomic.CompareAndSwapUint32(&done, 0, 1)，仅当当前为 0 时才设为 1，返回true表示首次执行成功 - 检查状态统一用
atomic.LoadUint32(&done) == 1，不要用done == 1 - 避免写成
if done == 0 { atomic.StoreUint32(&done, 1) }——这中间有竞态窗口
指针类型热更新配置要用 unsafe.Pointer + StorePointer/LoadPointer
热路径中替换整个配置结构体（比如 *Config）时，不能先改字段再赋值指针，也不能用 mutex 包裹整个 swap 过程——那会卡住所有读请求。正确做法是把新配置写入堆后，用原子指针交换一次完成发布。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 声明变量为
var configPtr unsafe.Pointer，初始化时用atomic.StorePointer(&configPtr, unsafe.Pointer(&initialConfig)) - 更新时：构造新
*Config→ 调用atomic.StorePointer(&configPtr, unsafe.Pointer(newCfg)) - 读取时：用
cfg := (*Config)(atomic.LoadPointer(&configPtr))强转，确保看到完整、一致的新结构体 - 注意：被指向的结构体必须是只读的（字段不再修改），否则仍需额外同步；也不支持原子更新结构体内单个字段
CAS 循环写入比 Add 更耗 CPU，热路径慎用无界重试
atomic.CompareAndSwap 是无锁算法核心，但在高冲突场景下可能反复失败重试，反而比短临界区的 mutex 更伤性能。热路径中若用 CAS 实现“累加带阈值控制”，要限制重试次数或退化策略。
- 例如实现“每万次请求打点一次”，别写无限 for 循环调
CompareAndSwapInt64，而应先atomic.AddInt64，再用模运算判断是否到边界 - 若必须 CAS（如实现自旋锁），加
runtime.Gosched()防止单核忙等，或设置最大重试 10–100 次后 fallback 到 mutex - 所有 CAS 操作都要检查返回值：
if !atomic.CompareAndSwapInt64(&x, old, new) { continue }，漏判等于放弃原子性保障
实际热路径中最容易被忽略的是：**atomic 操作本身不提供 happens-before 语义的自动传播**。比如你用 atomic.StoreInt64 写完计数器，另一个 goroutine 紧接着读，理论上能看到最新值——但若中间没任何同步动作（如 channel send/receive、mutex unlock），Go 内存模型不保证该读一定观察到那次写。生产环境建议搭配 sync/atomic 的 Load/Store 成对使用，或在关键路径末尾插入 runtime.GC()（仅调试）验证可见性，否则压测时可能偶发旧值。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
