Go中必须用sync.Mutex的场景是多个goroutine同时读写同一变量且至少有一个写操作时；正确用法是细粒度加锁、defer解锁、避免嵌套；读多写少可用RWMutex；优先考虑atomic或channel替代。
Go 里没有“锁住整个函数”的魔法，sync.Mutex 必须显式加锁、解锁，且只保护你明确包裹的那段共享数据访问逻辑。
什么时候必须用 sync.Mutex？
当多个 goroutine 同时读写同一个变量（比如 int、map、结构体字段），且至少有一个是写操作时，就存在竞态（race）。Go 的 go run -race 会报类似 Data race on field ... 的错误。
- 常见场景：计数器累加（
counter++）、缓存 map 的增删改查、状态标志位更新 - 注意：
map本身不是并发安全的——哪怕只是多个 goroutine 同时read，只要其中有一个write，就必须加锁 - 别依赖“我只读不写就安全”：如果其他 goroutine 在写，你的读可能看到中间态或 panic（如 map 扩容时）
sync.Mutex 的正确使用姿势
核心原则：锁的粒度越小越好，只包住真正需要同步的代码段；必须成对出现，且不能在锁内调用可能阻塞或 panic 的不可控逻辑。
- 用
mu.Lock()和mu.Unlock()，不是mu.Lock或mu.Unlock()（少括号是常见拼写错误） - 推荐用
defer mu.Unlock()确保解锁，但要放在Lock()之后立即写，否则可能锁还没拿到就 defer 了 - 避免锁嵌套：goroutine 拿着 A 锁再去等 B 锁，另一个拿着 B 锁等 A 锁 → 死锁。Go 不检测这种逻辑死锁
- 示例：
var mu sync.Mutex var count int func increment() { mu.Lock() defer mu.Unlock() // 这行必须紧跟 Lock 后 count++ }
sync.RWMutex 适合读多写少的场景
当读操作远多于写操作（比如配置缓存、白名单列表），用 sync.RWMutex 可以让多个 goroutine 并发读，只在写时独占。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
RWMutex.RLock()和RWMutex.RUnlock()用于读；RWMutex.Lock()/Unlock()用于写 - 注意：
RLock()不会阻塞其他RLock()，但会阻塞Lock()；反过来，一旦有 goroutine 调用了Lock()，所有新的RLock()都会被阻塞，直到写完成 - 不要在持有
RLock()时去调用Lock()—— 会死锁（Go 不允许升级锁） - 如果读操作里包含复杂计算或网络调用，别为了“读锁”而锁太久，反而拖慢写操作
比 mutex 更轻量或更语义化的替代方案
不是所有并发问题都该用 Mutex。优先考虑 Channel 或 sync/atomic。
- 纯数值计数（
int32,int64,uint64,unsafe.Pointer）：用atomic.AddInt64(&count, 1)，无锁且更快 - 需要协调 goroutine 生命周期或传递信号：用
chan struct{}或带缓冲的 channel，比如 “worker 等待任务”、“主协程等待全部 worker 结束” - 一次初始化（如单例、全局配置加载）：用
sync.Once，比手写双重检查锁更简洁安全 - 别把
mutex当成“防止并发执行”的通用开关——它只保数据一致性，不保执行顺序
最容易被忽略的是：锁保护的是“内存位置”，不是“变量名”。如果两个 goroutine 通过不同路径访问同一个底层结构体字段，或者通过指针共享了同一块内存，只锁局部变量名没用。得确认你锁住的 mu 实例，确实和你要保护的数据在同一个作用域、同一生命周期里。
