当读写频率接近（如6:4或5:5）、写操作频繁（>20%）、临界区极短、需锁升级或强一致性保障时，应选sync.Mutex；它更简单可靠，避免写饥饿与死锁风险。
什么时候该用 sync.Mutex，而不是 sync.RWMutex
当读写操作频率接近（比如 6:4 或 5:5），或者写操作逻辑复杂、需强一致性保障时，sync.Mutex 更简单可靠。它不区分读写，所有操作都排队，避免了锁升级/降级、写饥饿等隐含风险。
- 写操作频繁（>20% 的并发请求是写）：用
RWMutex反而会让写 goroutine 长时间等待，因为新读请求会不断插队（Go 的RWMutex是写优先但「读不阻塞读」，导致写被持续延迟） - 临界区极短（如只改一个字段、查一个 map key）：加锁开销本身已占主导，
RWMutex多出的状态管理反而略慢 - 需要在持有读锁期间“升级”为写锁：这是禁止的——
RWMutex不支持锁升级，强行RLock()后再Lock()会导致死锁
sync.RWMutex 真正发挥优势的场景
典型读多写少：读操作占比 ≥ 80%，且读逻辑耗时明显（如遍历 map、序列化结构体、计算聚合值）。这时多个 goroutine 并发 RLock() 不互斥，吞吐量能线性提升。
- 配置缓存：配置只在后台定时更新（写少），但每个 HTTP 请求都要读取（读多）
- 状态快照：服务暴露
/health或/metrics接口，需读取大量只读指标 - 内存索引：如倒排索引、路由表，查询远多于重建
注意：RWMutex 的 Lock() 会阻塞后续所有 RLock()，所以写操作一旦变慢（比如触发磁盘 IO 或网络调用），读请求就会集体卡住——这不是 bug，是设计使然。
常见误用与 panic 原因
两类锁都要求「谁 Lock 谁 Unlock」不是硬性限制（Go 允许跨 goroutine 解锁），但实际中极易出错。真正会 panic 的是以下操作：
立即学习“go语言免费学习笔记（深入）”；
- 对未加锁的
sync.Mutex或sync.RWMutex调用Unlock()→ panic: "sync: unlock of unlocked mutex" - 对未加读锁的
RWMutex调用RUnlock()→ panic: "sync: RUnlock of unlocked RWMutex" - 拷贝已使用的锁变量（如结构体赋值、map value 传递）→ 锁状态丢失，出现竞态或静默失效
正确姿势：始终用 defer mu.Unlock() 或 defer rw.RUnlock()；锁变量必须是地址传递或全局/成员变量，禁止值拷贝。
性能差异到底有多大？别猜，看实测倾向
小并发（≤10 goroutines）下，两者差距微乎其微；但高并发读场景（100+ goroutines 持续 RLock()），RWMutex 的读吞吐可比 Mutex 高 3–5 倍。不过写性能更差——因为每次 Lock() 都要等所有现存读锁释放，且新读请求会被挂起。
简单验证逻辑：
var m sync.Mutex
var rw sync.RWMutex
var data = make(map[string]int)
// 写操作（两者共用）
func write(k string, v int) {
m.Lock()
data[k] = v
m.Unlock()
// 或用 rw.Lock() / rw.Unlock()
}
// 读操作（关键区别）
func readMutex(k string) int {
m.Lock()
defer m.Unlock()
return data[k]
}
func readRWMutex(k string) int {
rw.RLock()
defer rw.RUnlock()
return data[k]
}
真实压测前，先问自己：你的读写比例是多少？写操作是否可能阻塞？有没有 goroutine 在锁内做网络/IO？这些比选哪个锁更重要。
