atomic.addint64与loadint64安全高效，但类型错误、地址不对齐或混用普通赋值必致编译失败或panic；函数必须传*int64指针且变量可寻址，32位平台未对齐会直接panic，复合逻辑（如加后判断）须用cas或mutex。
直接用 atomic.AddInt64 增减、atomic.LoadInt64 读取，是安全且高效的；但类型错、地址不对齐、混用普通赋值，三者任一都会导致编译失败或运行时 panic，不是“偶尔出问题”，而是必然失败。
atomic 函数必须传指针，且变量必须可寻址
所有 atomic.XxxInt64 等函数签名都要求 *int64，传值会直接编译报错：cannot use x (type int64) as type *int64。更隐蔽的是“不可寻址”场景：
-
atomic.AddInt64(&42, 1)❌ 字面量无地址 -
atomic.AddInt64(&m["count"], 1)❌ map 值不可取地址 -
atomic.AddInt64(&getCounter(), 1)❌ 函数返回值是临时对象，不可取址 - 局部变量一般可寻址，但若逃逸到堆上且未对齐（尤其
GOARCH=386），运行时可能 panic
int64 在 32 位平台可能 panic，对齐不是可选项
atomic.LoadInt64 和 atomic.StoreInt64 底层依赖 CPU 的 8 字节对齐原子指令。在 32 位系统（如 ARMv7 或 386）上，若 int64 字段在 struct 中偏移不是 8 的倍数，会直接 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误示例：
type S { x uint32; y int64 }→y偏移为 4，未对齐 - 修复方式：把
int64放 struct 开头，或加 padding：_ [4]byte - 验证方法：交叉编译测试
GOARCH=386 go run main.go，别只信本地 64 位环境
别用 atomic 实现“加完判断”，它不提供复合原子性
atomic.AddUint64(&x, 1) 本身是原子的，但它只保证“加”这一步，不保证“加完再比较是否超阈值”这个整体逻辑。常见误用：
-
if atomic.AddUint64(&x, 1) > 100 { ... }—— 这里比较和后续分支不是原子的，多个 goroutine 可能同时触发 - 正确做法：用
atomic.CompareAndSwapUint64循环重试，或改用sync.Mutex包裹复合逻辑 - 状态切换（如初始化、开关）优先用 CAS：
atomic.CompareAndSwapInt32(&state, 0, 1)，天然幂等
复杂类型只能用 atomic.Value，但它不支持增减
map、struct、slice 等不能直接原子操作。想“原子替换整个配置”，必须用 atomic.Value：
-
var cfg atomic.Value，然后cfg.Store(&MyConfig{...})和cfg.Load().(*MyConfig) - 存入的值必须可比较（能用于
==），含map、func、sync.Mutex的 struct 会 panic -
atomic.Value只保证“替换”动作原子，不提供字段级更新能力，也不支持Add类操作 - 需要字段级原子更新？说明设计已超出 atomic 范畴，该用 mutex 或重构为不可变结构 + 整体替换
最常被忽略的一点：atomic 不是性能银弹，它是窄口径工具——只解决“单个基础类型变量的单步操作”这一件事。一旦逻辑涉及多变量、条件分支、复合判断，就该果断退回到 sync.Mutex 或 channel，强行硬套只会让 bug 更难定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
