Go sync库提供底层同步原语，需依场景慎选：读多写少且读耗时才用RWMutex；Once仅保首次成功，panic后不再重试；WaitGroup.Add须在goroutine启动前调用；Map适用于长生命周期key的高读低写场景。
Go 的 sync 库不是“万能锁工具箱”，它提供的是底层同步原语，用错场景或组合方式反而会引发死锁、竞态或性能退化。
什么时候该用 sync.Mutex 而不是 sync.RWMutex
读多写少且读操作耗时明显（比如遍历大 map 或解码结构体）时，sync.RWMutex 才有收益；否则直接用 sync.Mutex 更简单安全。
-
sync.RWMutex的写锁会阻塞所有新读锁，而读锁之间不互斥——但一旦有 goroutine 在等写锁，后续所有读锁都会排队，可能造成“写饥饿” - 对小数据（如单个
int64）做保护时，用sync.Mutex比sync.RWMutex内存开销更小、调用更快 - 不要在 defer 中混用：比如
defer mu.RLock()是无效的，必须配对mu.RUnlock()
sync.Once 的常见误用：以为它能控制多次执行，其实只保“首次成功”
sync.Once.Do() 不是“限流器”，也不保证函数一定执行——如果传入的函数 panic，sync.Once 会记录“已尝试”，后续调用不再执行，也不会恢复 panic。
- 典型错误：把初始化数据库连接写在
Do()里，但连接失败 panic，导致后续所有调用都静默跳过 - 正确做法：在函数内部处理错误，用返回值或全局变量暴露状态，例如：
var initErr error var once sync.Once once.Do(func() { initErr = connectDB() }) -
sync.Once无法重置，需要重试逻辑时，应改用sync.Mutex+ 标志位
sync.WaitGroup 的计数陷阱：Add 必须在 goroutine 启动前调用
WaitGroup.Add() 如果在 goroutine 内部调用，极大概率触发 panic：panic: sync: negative WaitGroup counter，因为 Done() 可能在 Add() 前执行。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须在
go语句之前调用wg.Add(1)，不能在 goroutine 函数体开头 - 如果启动数量动态（如从 channel 收消息后起 goroutine），需先用循环确定总数，再批量
Add()，再启动 - 避免在循环中重复声明
sync.WaitGroup：局部变量每次迭代新建，Wait()永远不会返回
sync.Map 并不适合替代普通 map + Mutex
sync.Map 是为“读远多于写、且 key 生命周期长”的场景优化的，高频写入或频繁创建/销毁 map 时，它比加锁 map 更慢、内存更高。
- 不支持
range遍历，必须用Range()方法，且回调中不能修改 map（否则 panic） - 没有
len()，要统计长度只能遍历，O(n) 时间复杂度 - key 类型必须可比较（和普通 map 一样），但 value 类型无限制——这点常被忽略，导致类型断言失败
- 如果你的代码里出现
sync.Map.LoadOrStore调用频率和Store相当，说明它没发挥优势，应回退到map + sync.RWMutex
真正难的不是记住每个原语怎么写，而是判断哪个原语在什么负载特征、什么生命周期、什么错误容忍度下才真正合适。比如 sync.Pool 在对象复用上看似省 GC，但若 Put 进去的对象被外部引用，就会泄漏；这些边界条件，文档不会主动告诉你，只有压测和 pprof 看到 goroutine 阻塞在 mutex.lock 时才意识到——原来当时选错了。
