Go并发中需用sync.Mutex或sync.RWMutex控制共享资源访问：Mutex适用于读写均需互斥的场景，RWMutex适用于读多写少场景；应优先通过channel避免共享内存，并用-race检测数据竞争。
在 Go 并发编程中，多个 goroutine 同时读写同一变量极易引发数据竞争（data race），导致程序行为不可预测。解决这个问题的核心是**控制对共享资源的访问顺序和权限**，Go 提供了 sync.Mutex（互斥锁）和 sync.RWMutex（读写锁）两种基础同步原语，它们不是“万能药”，而是需要按场景合理选用的工具。
互斥锁（Mutex）：读写都得排队
当你需要确保**任意时刻最多只有一个 goroutine 能访问共享资源**（无论是读还是写），就用 sync.Mutex。它简单、开销小，适合写操作频繁或读写比例接近的场景。
- 调用
mu.Lock()获取锁，mu.Unlock()释放锁；务必成对出现，推荐用defer mu.Unlock()防止遗漏 - 锁的作用范围应尽量小——只包裹真正需要保护的代码段，避免把网络请求、日志打印等耗时操作包进去
- 不要在持有锁时调用可能阻塞或重入的函数（比如再次 Lock 同一把锁），否则会死锁
读写锁（RWMutex）：读多写少时更高效
当共享资源**读操作远多于写操作**，且读操作本身不改变数据时，sync.RWMutex 更合适。它允许多个 goroutine 同时读，但写操作必须独占（排他）。
- 读操作用
mu.RLock()/mu.RUnlock()，写操作用mu.Lock()/mu.Unlock() - RWMutex 不是“读优先”或“写优先”的严格保证，但实际调度中写操作可能被大量读操作饿死，所以不适合写较频繁的场景
- 注意：
RLock()和Lock()不能混用——即不能用 RUnlock() 去释放 Lock() 获得的锁
常见误区与实用建议
锁只是手段，不是目的。很多并发问题其实可以通过设计规避，而非堆砌锁逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 优先考虑“无共享通信”：用 channel 传递数据，而不是让多个 goroutine 共享一个变量（Go 的信条：“Don’t communicate by sharing memory; share memory by communicating.”）
- 结构体字段级加锁要谨慎：如果只有一两个字段需保护，可单独提取为带锁的小结构，避免整个结构体被锁住影响性能
- 运行时检测数据竞争：
go run -race main.go是开发阶段必做的检查，它能帮你发现隐性 race，比靠经验猜测可靠得多 - 避免全局锁：如非必要，不要把
sync.Mutex声明为包级变量并到处使用，容易造成耦合和误用
基本上就这些。锁用对了能保安全，用错了反而拖慢程序还藏隐患。关键是理解“谁在什么时候需要访问什么”，再选最轻量、最贴切的同步方式。
