不能直接用int当计数器，因非原子操作会导致竞态——counter++在汇编层为读-改-写三步，多goroutine并发时结果必然不可靠；必须用sync.Mutex或sync/atomic，后者要求显式使用uint64等对齐类型并配对Load/Store/Add操作。
为什么不能直接用 int 当计数器
多个 goroutine 同时读写一个 int 变量，不加同步会出错——不是“偶尔错”，而是“必然不可靠”。Go 的内存模型不保证非原子操作的可见性和顺序性，哪怕只是 counter++ 这种看似简单的语句，在汇编层也是“读-改-写”三步，中间可能被其他 goroutine 插入修改，结果丢失。典型现象是：启 10 个 goroutine 各自加 1000 次，最后 counter 值远小于 10000，且每次运行结果还不一样。
常见错误写法：
var counter int<br>go func() { counter++ }()这完全没做同步，等同于裸奔。
解决思路只有两个：锁（sync.Mutex）或原子操作（sync/atomic）。前者通用但有锁开销；后者轻量、无锁、适合简单数值操作——这正是 sync/atomic 的定位。
Atomic.LoadUint64 和 Atomic.AddUint64 怎么配对用
Go 的 atomic 包不支持 int 类型的原子操作（避免符号扩展歧义），必须显式用带类型后缀的函数，最常用的是 uint64。别试图用 int64 的版本去存负数计数器——虽然能编译，但一旦涉及位运算（比如 LoadInt64 底层仍按补码解释），在跨平台或和 C 交互时容易翻车。
正确配对方式：
- 初始化用
var counter uint64（不是int） - 读取用
atomic.LoadUint64(&counter)（不能直接读变量） - 累加用
atomic.AddUint64(&counter, 1)（传地址，第二个参数是uint64） - 重置用
atomic.StoreUint64(&counter, 0)
示例片段：
var hits uint64<br>go func() { atomic.AddUint64(&hits, 1) }()<br>fmt.Println(atomic.LoadUint64(&hits)) // 安全读
为什么 Atomic 不适用于复杂状态更新
sync/atomic 只管单个值的原子读写或简单算术，没法保证“读 A → 改 B → 写 C”这种多步逻辑的原子性。比如想实现“只在计数器为偶数时才加 1”，用 if atomic.LoadUint64(&c)%2 == 0 { atomic.AddUint64(&c, 1) } 是错的——两次原子调用之间，c 可能已被别的 goroutine 改过，条件失效。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
这时候必须换方案：
- 用
atomic.CompareAndSwapUint64手动实现 CAS 循环（适合简单条件） - 或者直接上
sync.Mutex，代码更直白，性能差异在绝大多数场景下可忽略
别为了“看起来无锁”硬套 atomic——它不是万能补丁，只是工具箱里一把小螺丝刀。
在 struct 里嵌入 atomic 字段要注意什么
如果把 uint64 字段塞进 struct，又想原子操作，得确保它在内存中没有被编译器“挤在一起”导致误读。Go 要求原子变量必须是 64 位对齐的，而 struct 成员顺序和 padding 由编译器决定。
安全做法：
- 把原子字段声明在 struct 第一个位置（最保险）
- 或者用
align64标签（Go 1.21+）显式对齐：count uint64 `align64` - 绝对不要用
unsafe.Offsetof算偏移再手动操作——破坏类型安全，且 Go 版本升级可能让布局变化
错误示范：
type Counter struct {<br> name string<br> count uint64 // 可能不对齐！<br>}这样
atomic.LoadUint64(&c.count) 在某些平台会 panic “unaligned 64-bit atomic operation”。
真正麻烦的从来不是“怎么写对”，而是“什么时候不该用”。Atomic 看似简单，但类型选择、内存对齐、复合逻辑边界，哪一环松动都会让并发行为滑向不可预测。写完记得跑 go run -race，别信感觉。
