热路径并发冲突应优先确认是否真需同步，而非直接加锁；atomic操作快因是单指令无调度，但须满足单字段、无依赖等条件，混用普通读写将导致未定义行为。
热路径上出现并发冲突，不是该换锁，而是该确认是否真需要“同步”——多数时候是误用了非原子操作读写共享状态，或把原子操作当万能锁用。直接上 sync.Mutex 只会掩盖问题，还拖慢吞吐。
atomic.LoadInt64 为什么比 RWMutex.RLock() 快一个数量级？
因为它是单条 CPU 指令（或等效的内存屏障），无调度、无锁队列、不触发 goroutine 阻塞。但前提是：只读单个整型字段，且不依赖其他变量状态。
- ✅ 适用：监控指标采样（
atomic.LoadInt64(&reqCount)）、服务就绪检查（atomic.LoadUint32(&ready)） - ❌ 不适用：读
data和version两个字段并校验一致性——atomic.LoadInt64不保证看到data的最新值 - ⚠️ 坑点：如果刚用
data = "new"赋值，再用atomic.StoreUint32(&version, 2)，其他 goroutine 单独调用atomic.LoadUint32(&version)可能看到新 version，但data还是旧的——必须用原子操作配对才能建立 happens-before
结构体里放 int64 字段，为什么一调 atomic 就 panic？
Go 要求 64 位原子操作作用于 8 字节对齐地址，而 struct 字段顺序会影响实际偏移。未对齐时，在 ARM 或开启 -gcflags="-d=checkptr" 的环境下直接崩溃。
- ✅ 推荐：把
int64放 struct 第一个字段，或前面补_ [0]uint64强制对齐 - ✅ 更稳：用
atomic.Value包一层指针，绕过对齐问题（适合配置热更新） - ⚠️ 坑点：不要对局部变量取地址后传给其他 goroutine 长期持有——栈回收后
&localVar变成悬垂指针
CompareAndSwap 循环里为什么总失败？
atomic.CompareAndSwapInt64 返回 false 是并发常态，不是 bug。它只表示“你基于的旧值已过期”，必须重试。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 标准写法必须带
for循环：old := atomic.LoadInt64(&state)→ 判断 →CompareAndSwapInt64(&state, old, new) - 别省略
atomic.LoadInt64直接用缓存的old，中间可能已被他人修改 - 高竞争下可加
runtime.Gosched()避免空转占满 CPU，但绝不能加time.Sleep——它放大延迟且破坏调度公平性 - 如果每秒 CAS 失败上千次，说明不适合用 CAS，该换
sync.Mutex或分片计数
atomic.Bool 为什么 if done.Load() 编译不过？
它编译得过——done.Load() 返回 bool，if done.Load() 完全合法。真正常见错误是混淆了变量名和方法调用：
- ❌ 错误：
if done（done是atomic.Bool类型，不能直接用于布尔上下文） - ❌ 错误：
done = true（atomic.Bool不支持赋值，必须用done.Store(true)） - ✅ 正确：
done.Store(true)写，done.Load()读，语义清晰、类型安全 - ⚠️ 坑点：旧代码若用
int32模拟布尔（如atomic.StoreInt32(&flag, 1)），请尽快迁移——Go 运行时不保证非 0/1 值在Load后仍被当true解释
最易被忽略的一点：所有对同一变量的读写，必须统一走 atomic 函数。混用普通赋值（counter = 10）或裸读（val := counter）不会报错，但结果不可预测——竞态检测器（go run -race）能抓到，但上线后靠它兜底等于没防。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
