sync.RWMutex 更适合读多写少场景，因其允许多读并发、写独占；但需避免锁内重操作、不可嵌套或混用锁，且无读锁升级机制。
为什么读多写少时 sync.RWMutex 比 sync.Mutex 更合适
因为 sync.RWMutex 允许多个 goroutine 同时读，但写操作会独占锁；而 sync.Mutex 无论读写都串行。当数据结构被高频读取、低频更新（比如配置缓存、路由表、连接池状态）时，RWMutex 能显著减少 goroutine 阻塞。
注意：它不是“一定更快”，而是“在读远多于写的场景下才体现优势”。如果读写比例接近 1:1，甚至写更多，RWMutex 的额外开销（如读计数器维护、唤醒逻辑）反而可能拖慢性能。
RWMutex 的读锁和写锁必须成对使用，漏掉 Unlock() 会导致死锁
常见错误是 defer RLock() / RUnlock() 写反，或在分支中提前 return 却没 unlock。Go 不会自动释放锁，也不会报错，只会在后续 goroutine 等待时无限阻塞。
推荐写法：
// ✅ 安全：RLock 后立刻 defer RUnlock
mu.RLock()
defer mu.RUnlock()
return data
// ❌ 危险：if 分支里没 unlock
mu.RLock()
if cond {
mu.RUnlock() // 忘了？或者没覆盖所有路径？
return err
}
// 这里没 unlock 就 return → 死锁
更稳妥的做法是把读逻辑封装进函数，或统一用 defer —— 只要 RLock() 成功，就一定 defer RUnlock()。
写操作会阻塞新读请求，但已获得读锁的 goroutine 不会被中断
这是 RWMutex 的关键语义：写锁调用 Lock() 时，会等待所有当前持有读锁的 goroutine 完成并释放锁，但不会强行终止它们。这意味着：
- 正在执行
RLock()+ 处理耗时逻辑的 goroutine，会继续跑完再释放锁 - 新来的
RLock()请求会被挂起，直到写锁释放 - 如果读操作本身很慢（比如遍历大 slice + JSON 序列化），写操作就得等很久
所以别在读锁里做重操作。例如：
mu.RLock() defer mu.RUnlock() result := slowProcess(data) // ❌ 把耗时逻辑放锁内，拖慢写操作 return result
应改为：
mu.RLock() dataCopy := copyData(data) // ✅ 只做轻量拷贝 mu.RUnlock() return slowProcess(dataCopy) // 在锁外处理
不能嵌套使用 RWMutex，且与 Mutex 混用会破坏语义
RWMutex 不支持同 goroutine 多次 RLock()（即不可重入），也不允许在持有读锁时调用 Lock() —— 这会直接死锁。同样，持有写锁时再 RLock() 也不行。
另外，别拿 sync.Mutex 去保护同一块数据：它无法感知 RWMutex 的读状态，会导致数据竞争或不一致。一个变量只能由一种锁机制保护。
典型陷阱：
mu.RLock()
// ...
if needUpdate {
mu.Lock() // ❌ 死锁：已在读锁中尝试获取写锁
defer mu.Unlock()
}
正确做法是先释放读锁，再尝试获取写锁（注意检查条件是否仍成立）：
mu.RLock()
value := data.value
mu.RUnlock()
if needUpdate(value) {
mu.Lock()
if needUpdate(data.value) { // 再检查，防止竞态
data.value = newValue
}
mu.Unlock()
}
真正难处理的是读锁内需要动态决定是否升级为写锁的场景 —— Go 标准库不支持“读锁升级”，必须手动释放+重试，容易出错。这种逻辑越复杂，越建议换用更高级的并发原语（如 sync.Map 或带版本号的无锁结构），而不是硬啃 RWMutex 的限制。
