读多写少场景用RWMutex因允许多读一写，提升并发吞吐；但写频繁或读极短时Mutex更优，且RWMutex不保证读写绝对顺序、不支持TryLock，复合操作需双检锁等上层保障。
为什么读多写少场景下要用 RWMutex 而不是 Mutex
因为 RWMutex 允许多个 goroutine 同时读，但写操作会独占锁；而 Mutex 无论读写都互斥。在读远多于写的场景（比如配置缓存、状态快照），用 RWMutex 能显著提升并发吞吐。但要注意：它不保证读写之间的“绝对顺序”，比如一个写操作正在等待时，新来的读请求仍可能插队获取读锁——这不是 bug，是设计使然。
RWMutex 的四个核心方法怎么配对使用
必须严格区分读/写路径，否则会死锁或数据竞争：
-
RLock()和RUnlock()成对用于只读操作；不能在持有Rlock期间调用Lock() -
Lock()和Unlock()成对用于写操作；此时所有新RLock()会被阻塞，直到Unlock() - 禁止嵌套：不能在已持
RLock()的 goroutine 中再调Lock()，这会永久阻塞 - 忘记
Unlock()或RUnlock()是常见 panic 来源，建议用defer mu.RUnlock()保底
什么时候 RWMutex 反而比 Mutex 更慢
当写操作频繁（比如每秒数百次以上）或读操作极短（纳秒级），RWMutex 的额外状态管理开销（如维护 reader 计数、唤醒策略）可能超过收益。实测发现，在写占比 >15% 且临界区极小时，Mutex 往往更稳。另外，RWMutex 不支持 TryLock 类语义，无法做非阻塞探测，这点常被忽略。
一个易错的典型误用模式
下面这段代码看似合理，实则危险：
