sync.Once不能用于计数器更新，因其仅保证初始化函数执行一次，不提供原子读写能力；counter++需独立同步机制，否则并发下值异常。
为什么 sync.Once 不能直接用于计数器更新
因为 sync.Once.Do 只保证初始化函数执行一次，不提供原子读写能力。把它套在 counter++ 外面，看似“只跑一次”，实际每次调用仍会进入临界区竞争，反而掩盖了真正的并发问题。
- 常见错误现象：
counter值远低于预期，尤其在高并发压测下跳变明显 - 本质原因：计数操作（读-改-写）不是原子的，即使初始化用了
sync.Once，后续递增仍需独立同步机制 - 正确思路：单例负责实例创建，计数逻辑必须另配原子操作或互斥锁
sync/atomic 做计数器比 sync.Mutex 快在哪
底层直接映射到 CPU 的 LOCK XADD 等指令，无 goroutine 调度开销；而 sync.Mutex 在争抢激烈时可能触发休眠唤醒，延迟不可控。
- 适用场景：仅需整型增减、比较交换等简单操作，比如请求计数、开关状态位
- 参数差异：
atomic.AddInt64(&counter, 1)要求变量地址是*int64，不能传值或接口类型 - 兼容性注意：32 位系统上
int64非原子，必须用atomic.Int64类型（Go 1.19+）或确保 64 位对齐
全局单例 + 原子计数的标准结构长什么样
单例本身应惰性初始化、线程安全，内部字段用 atomic.Int64 或原始类型配合 atomic 函数，避免暴露可变字段。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要这样写：
var Counter = &CounterStruct{val: 0}—— 包级变量初始化无同步保障 - 推荐结构：
var instance *Counter
var once sync.Once
func GetCounter() *Counter {
once.Do(func() {
instance = &Counter{val: atomic.Int64{}}
})
return instance
}
type Counter struct {
val atomic.Int64
}
func (c *Counter) Inc() int64 {
return c.val.Add(1)
}
- 容易踩的坑：把
atomic.Int64字段设为 public，外部直接调c.val.Store()—— 破坏封装，且绕过业务逻辑校验
什么时候非得换 sync.Mutex 不可
当计数逻辑耦合条件判断、多字段联动或需要精确控制临界区范围时，atomic 就不够用了。比如“每 100 次请求触发一次日志”，涉及读取、判断、重置三步，无法用单个原子操作表达。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：用
atomic.LoadInt64读值后做 if 判断，再用atomic.StoreInt64写回 —— 中间窗口期被其他 goroutine 修改，导致逻辑错乱 - 此时必须用
mutex.Lock()/Unlock()包住整个复合操作 - 性能提示：若该分支极少触发（如万分之一），用
atomic.Load先快速路径检查，命中后再加锁，能显著降低锁竞争
真正难的不是选原子还是锁，而是厘清“哪些操作必须视为一个不可分割单元”——这个边界一旦画错，再多的同步原语也救不回来。
