RWMutex仅在读占比≥70%时显著优于Mutex，读占比＜40%时反更慢且易死锁；推荐按读写比例分段选型，并优先考虑sync.Map或分片锁等替代方案。
读多写少时 RWMutex 确实快，但读占比低于 40% 就别硬上
Go 1.22 实测（8 核）显示：sync.RWMutex 在读操作 ≥ 70% 时吞吐量比 sync.Mutex 高 2–4 倍；但一旦读占比掉到 40% 以下，两者性能基本持平，甚至 RWMutex 因状态检查开销略慢。这不是理论推测——它每次 RLock() 都要原子读取并判断是否有等待中的写锁，而写锁又会阻塞所有新读请求，造成排队放大。
- 读占比 ≥ 70%：优先用
RWMutex，尤其适合缓存命中率高、配置只读、统计指标拉取等场景 - 读占比 40%–60%：直接用
sync.Mutex，省心、无状态切换风险、无写饥饿隐患 - 读占比 ≤ 40% 或写频繁：
RWMutex反而更慢，且易触发死锁（比如if x == 0 { mu.Lock(); x++ }这类“读中判后写”逻辑）
写操作一多，RWMutex 的 Lock() 就成瓶颈
sync.RWMutex.Lock() 不仅要获取写权限，还必须等待所有已持有的读锁释放——这意味着哪怕只有 1 个 goroutine 持有 RLock()，且它正在做耗时操作（比如序列化、网络调用），所有写请求都会卡住。而 sync.Mutex 没这层依赖，加锁路径最短，调度更可预测。
- 避免在
RLock()持有期间做任何非轻量操作（如json.Marshal、http.Get、循环遍历大 slice） - 若业务逻辑含「读→条件判断→写」模式（如懒加载初始化、计数器自增），强行用
RWMutex极易陷入死锁，此时必须退回到sync.Mutex - 写锁阻塞时，新来的
RLock()也会排队——不是“只阻塞写”，而是“写锁优先级最高，读写互斥”
命名和粒度比选哪种锁更重要
很多性能问题其实跟锁类型无关，而是锁变量命名模糊、保护范围过大。Go 社区约定：锁变量统一叫 mu（不是 mutex），或带语义后缀如 cacheMu、configMu，一眼就能看出它护着谁。
- 别把整个结构体用一个
mu包住，尤其是字段读写频率差异大时（比如一个字段高频读、另一个字段低频写） - 考虑分片锁（sharded lock）或
sync.Map替代粗粒度RWMutex，尤其在高并发读+偶发写场景下，sync.Map的读几乎无锁，实测常优于手写RWMutex - 用
go tool trace观察锁竞争热点，比凭感觉猜更可靠；runtime.SetMutexProfileFraction(1)可导出锁竞争采样数据
死锁陷阱：RWMutex 的交叉锁比 Mutex 更隐蔽
sync.Mutex 的交叉死锁容易复现（A 锁完等 B，B 锁完等 A），但 sync.RWMutex 的死锁常发生在「读锁未释放 + 写锁等待 + 新读锁排队」的组合里，堆栈看不出明显环路，调试成本更高。
- 永远用
defer mu.RUnlock()，别在分支里提前RUnlock()——漏掉一次就可能让后续写操作永久阻塞 - 禁止在持有
RLock()时调用可能间接获取写锁的函数（比如某个工具函数内部用了mu.Lock()） - 如果必须混合读写锁，建议显式拆成两个锁：
readMu和writeMu，而不是依赖RWMutex的状态切换
RWMutex 的使用边界，不如先确认：读写比例真有那么高吗？有没有更合适的替代方案（比如 sync.Map 或不可变快照）？锁的真正瓶颈，往往不在类型选择，而在是否真的需要锁。 
