sync.RWMutex本身不触发deadlock panic，但不当使用会导致静默卡死：写锁需等所有读锁释放，读锁在写锁等待时被阻塞，goroutine持续合法等待而CPU归零。
Go 高并发中 sync.RWMutex 本身不会直接引发 fatal error: all goroutines are asleep - deadlock!，但不当使用极易造成静默卡死（CPU 归零、goroutine 持续阻塞），尤其在读写混合、锁升级或嵌套场景下。核心问题不是“锁坏了”，而是你误以为读锁可无限叠加、写锁可随意插入——实际它有明确的获取优先级和阻塞规则。
为什么 RWMutex 会卡住而不报 panic？
sync.RWMutex 的设计决定了：一旦有 goroutine 正在写（Lock()），所有后续的读（RLock()）和写都会阻塞；而一旦有任意 goroutine 持有读锁，任何写操作都会等待所有读锁释放。它不触发运行时死锁 panic，是因为仍有 goroutine 在“合法等待”——只是这个等待可能永远持续。
常见静默卡死现象：
- 多个 goroutine 持有
RLock()，其中一个尝试Lock()升级，结果等不到所有读锁释放 - 写操作被大量并发读压住，迟迟无法获得独占权，下游依赖写结果的逻辑全挂起
- 在
RLock()持有期间调用另一个也需RWMutex的函数，且两处锁顺序不一致（AB-BA）
读锁不能升级为写锁，这是铁律
Go 的 sync.RWMutex 不支持“读锁 → 写锁”升级。试图在已持有 RLock() 的 goroutine 中调用 Lock()，会导致该 goroutine 永久阻塞（因为写锁必须等所有读锁释放，而它自己还占着一个）。
正确做法是：提前释放读锁，再申请写锁 —— 但这中间存在竞态窗口。所以更稳妥的是：
- 不要在读路径里临时决定要写；把“读-判-写”逻辑拆成两个明确阶段
- 若必须原子化，改用普通
sync.Mutex，或用 CAS +atomic替代锁 - 极端场景下，用
sync.Once或sync.Map规避锁升级需求
避免 RWMutex 与 Mutex 混用导致的 AB-BA 死锁
当代码同时使用 sync.RWMutex 和 sync.Mutex（或多个 RWMutex），且不同 goroutine 以不同顺序获取它们时，循环等待立刻成立。
例如：
var rw sync.RWMutex var mu sync.Mutex <p>// goroutine A: rw.RLock() mu.Lock() // 等 mu</p><p>// goroutine B: mu.Lock() rw.Lock() // 等 rw（因 A 持有 RLock，写锁需等全部读锁释放）
这种组合比纯 Mutex 更隐蔽，因为 RLock() 看似“无害”。防范方式只有一条：
- 全局约定锁获取顺序：比如始终先拿
sync.Mutex，再拿sync.RWMutex；或按变量名/地址排序，统一用uintptr(unsafe.Pointer(&rw)) < uintptr(unsafe.Pointer(&mu))判断 - 禁止在持有任一锁期间调用外部函数，除非你能 100% 确认它不获取其他锁
读多写少 ≠ 无脑上 RWMutex
sync.RWMutex 的读性能优势只在「读远多于写」且「读操作极轻量」时成立。一旦读操作变重（比如含复杂计算、网络调用、或内部又加了其他锁），读锁的共享性反而会放大争用——所有读 goroutine 被串行化在同一个写锁队列后面排队。
此时应评估：
- 是否真需要强一致性？能否接受
sync.Map的弱一致性语义 - 写操作是否真的稀疏？如果每秒写几次，而读几万次，RWMutex 合理；如果写频次接近读，
sync.Mutex可能更稳 - 是否可通过分片（sharding）把一个大
RWMutex拆成多个小锁，降低单点争用
最容易被忽略的一点：RWMutex 的 RLock() 不是免费的——它仍需原子操作更新 reader 计数器。高并发下，这个计数器本身就会成为热点。别把它当成“零成本读”。
