sync.Mutex 是保护共享变量最直接有效的方式，需作用于被竞争变量本身、避免锁内耗时操作、不可声明为局部变量；读多写少场景用 sync.RWMutex；简单整数/指针操作优先用 sync/atomic；必用 -race 检测竞态。
用 sync.Mutex 保护共享变量是最直接有效的方式
Go 的 goroutine 天然支持高并发，但多个 goroutine 同时读写一个变量（比如全局计数器、map、结构体字段）时，fatal error: concurrent map writes 或静默数据错乱就是典型表现。这时候不能靠“少写点”或“加 sleep”来缓解，必须显式同步。
关键不是“要不要锁”，而是“锁哪”和“锁多久”：
-
sync.Mutex必须作用于被竞争的变量本身，而不是外围逻辑；例如对map[string]int加锁，要确保所有读写都经过同一把mu - 避免在锁内做耗时操作（如 HTTP 请求、文件读写），否则会严重拖慢并发吞吐
- 不要把
mutex声明为局部变量——它必须是共享变量的“伴生字段”或包级变量，否则每次调用都新建一把锁，等于没锁
var mu sync.Mutex
var counts = make(map[string]int)
func inc(key string) {
mu.Lock()
counts[key]++
mu.Unlock()
}
用 sync.RWMutex 区分读多写少场景
当共享数据以读为主（比如配置缓存、路由表）、写极少（仅初始化或热更新），sync.RWMutex 能显著提升并发读性能。它的 RLock() 允许多个 goroutine 同时读，而 Lock() 仍是排他性的。
常见误用是：只对写操作加 Lock()，却对读操作完全不加 RLock()，导致读取时仍可能看到写到一半的中间状态。
- 读操作必须包裹在
RLock()/RUnlock()中，哪怕只是取一个字段值 -
RWMutex不是银弹——如果写操作频繁，它反而比普通Mutex开销更大 - 不能嵌套使用：在一个已持
RLock()的 goroutine 中再调Lock()会死锁
用 sync/atomic 替代锁处理简单整数或指针操作
对于 int32、int64、uint32、uintptr 和指针类型，sync/atomic 提供无锁原子操作，性能远高于 Mutex，且不会阻塞。
