go-deadlock 默认不检测 sync.rwmutex 的读锁重入和锁升级死锁，因其仅包装 sync.mutex；必须显式启用 rlock: true 才能捕获此类隐式死锁，否则服务会静默卡死。
go-deadlock 能检测 Go 网络服务里的死锁，但默认对 sync.RWMutex 的读锁重入和锁升级完全静默——不显式启用 RLock: true，就根本发现不了这类最常导致服务卡死的隐式死锁。
为什么 go-deadlock 默认不报 sync.RWMutex 读锁重入
标准库明确禁止同一个 goroutine 多次调用 mu.RLock()，或在已持读锁时调用 mu.Lock()。但 go-deadlock 默认只包装 sync.Mutex，所有 sync.RWMutex 实例都不受监控。结果就是：程序逻辑上已破坏锁约束，pprof 显示大量 goroutine 卡在 (*RWMutex).RLock 或 (*RWMutex).Lock，而 go-deadlock 一声不吭。
常见误判点：
- 看到 panic 日志里没有
fatal error: all goroutines are asleep - deadlock!，就以为没死锁——其实只是运行时没卡死，但业务请求已全量积压 - 用
-race检查没报错，就认为线程安全——但-race只管数据竞争，不管锁使用逻辑是否违规 - pprof 的
/debug/pprof/goroutine?debug=2显示一堆 goroutine 停在RLock，却归因为“下游慢”，没意识到是本层锁状态被污染
必须显式启用 RLock: true 才能捕获锁升级死锁
网络服务中典型的锁升级死锁链：HTTP handler 先 mu.RLock() 读缓存，再异步触发更新（比如调下游 API 后写回），而更新逻辑里直接 mu.Lock()——此时 goroutine 已持读锁，mu.Lock() 会永久阻塞；其他 goroutine 全部卡在 mu.RLock() 等待读权限，因为 RWMutex 内部计数器已被污染。
初始化时务必传完整选项：
-
deadlock.Init(deadlock.Opts{RLock: true, ReportAll: true})，缺一不可 -
ReportAll: true防止漏报——比如多个 goroutine 分别等不同锁，但未形成闭环，go-deadlock 仍会告警 - 仅在测试/开发环境启用；生产环境禁用，因它会跟踪每个 goroutine 的锁状态，带来可观开销
- 若第三方库内部用了
RWMutex导致兼容问题，改用白名单模式：只包装你自己的结构体字段，不全局替换
go-deadlock 必须全局替换 sync.Mutex 才生效
它不是静态分析工具，而是运行时插桩：所有锁操作都走 deadlock.Mutex 的 Lock()/Unlock() 方法，内部记录锁链、等待状态和调用栈。混用 sync.Mutex 和 deadlock.Mutex，后者对前者完全无感知。
实操要点：
- 不能只在测试里临时换一个变量类型——所有生产代码中用到
sync.Mutex的地方，都得显式声明为var mu deadlock.Mutex - 避免在
init()或包级变量中初始化deadlock.Mutex，否则可能被非测试代码意外触发 - 在单元测试中启用时，加构建标签控制：
//go:build testdeadlock，运行时用go test -tags=testdeadlock - 务必设置超时：
deadlock.Opts.DeadlockTimeout = 500 * time.Millisecond，防止测试卡死过久
网络服务死锁的典型特征与排查路径
关键特征不是 panic，而是服务响应延迟飙升、runtime.NumGoroutine() 持续上涨但无实际请求处理进展。pprof 查看 /debug/pprof/goroutine?debug=2，重点找：
- 大量 goroutine 停在
(*RWMutex).RLock或(*RWMutex).Lock - 同一把锁的
RLock和Lock出现在不同 goroutine 的堆栈里，且存在调用链交叠 - 用
go tool trace观察是否出现 “SyncBlock → Runnable → SyncBlock” 循环，这是锁升级失败的典型信号 - 绝不在已持有
mu.RLock()的 goroutine 中调用mu.Lock()；需要升级时，先mu.RUnlock()，再mu.Lock()（并重新校验状态）
最容易被忽略的是：这种死锁不会触发运行时的 all goroutines are asleep panic，也不被 -race 捕获，更不会出现在数据库日志里——它纯粹发生在 Go 层锁的使用逻辑中，必须靠配置正确的 go-deadlock 在测试阶段暴露。
