sync.RWMutex死锁表现为静默阻塞而非panic：RLock未配对RUnlock会导致写锁永久阻塞，goroutine卡在Lock()、CPU归零、协程数不降；读多写少时写饥饿或加锁顺序不一致亦引发同类问题。
sync.RWMutex 的死锁不是 panic 报错，而是静默卡住——写操作永远拿不到锁、goroutine 数稳定不降、CPU 归零，这才是最危险的。
RLock 未配对 RUnlock 导致写锁永久阻塞
同一个 goroutine 多次调用 RLock() 却没调够次数的 RUnlock()，Lock() 就再也没机会执行。Go 不报错，但所有后续写请求全挂死在 (*RWMutex).Lock 上。
- 典型错误：在函数开头无条件
defer mu.RUnlock()，但mu.RLock()后因 context 超时或 error 提前 return，导致 defer 执行了空解锁 - 安全写法：只在
mu.RLock()成功后才注册 defer，例如mu.RLock(); defer mu.RUnlock()必须紧挨着写在同一作用域 - 调试线索：pprof 查 goroutine stack，若大量停在
(*RWMutex).Lock且调用栈含业务读逻辑（如Get()），优先检查配对
读多写少场景下写饥饿引发逻辑卡死
当读请求密集（比如每毫秒数百次 RLock()），写操作长期抢不到锁，尤其写逻辑本身耗时（如加载远程配置），业务更新就失效了——监控指标不动、配置不生效，容易被当成“服务假死”而非锁问题。
- 写操作占比超 15%～20% 时，
sync.RWMutex的状态切换开销反超sync.Mutex，应直接换回普通互斥锁 - 读路径里禁止隐含写行为：例如
Get(key)中顺手更新lastAccess[key]，会让读锁变成写竞争源 - 强一致性写需求建议改用双缓冲 +
atomic.Value：新数据加载完再原子切换指针，完全规避锁竞争
多个 RWMutex 加锁顺序不一致触发 AB-BA 循环等待
和 sync.Mutex 一样，goroutine A 按 mu1→mu2 顺序加锁，goroutine B 按 mu2→mu1 顺序加锁，就会形成循环等待。运行时不报错，现象是部分 goroutine 卡在 RLock()、部分卡在 Lock()，数量稳定不减。
- 统一加锁顺序：按变量名字符串排序，或用
uintptr(unsafe.Pointer(&mu1)) 比较地址 - 禁止嵌套锁：函数 A 已持
mu1.RLock()，B 又尝试mu2.Lock()—— 这种调用链极易演变成循环依赖 - 跨函数传递结构体时，绝不能把已加读锁的对象传进去再解锁；锁的生命周期必须严格限定在单个函数作用域内
真正难防的不是 panic 型死锁，而是那些不报错、不崩溃、只悄悄让写操作失效的隐形卡顿。配对、顺序、粒度、逃逸——四个点里漏掉一个，就可能让服务在高并发下“安静地坏掉”。
