能，但需显式配置deadlock.Opts{RLock: true}；默认不检测sync.RWMutex读锁重入，而该行为在标准库中被明确禁止，会导致其他goroutine永久阻塞在Lock或RLock上。
go-deadlock 能检测 sync.RWMutex 读锁重入吗
能，但需配置启用。默认情况下 go-deadlock 只替换 sync.Mutex，对 sync.RWMutex 不生效；必须显式启用读写锁检测：deadlock.Opts{RLock: true}。否则即使同一个 goroutine 连续调用两次 mu.RLock()，也不会触发告警——而这种调用在标准库中是明确禁止的，会导致其他 goroutine 永久卡在 mu.Lock() 或后续 mu.RLock() 上。
实操建议：
- 初始化时传入完整选项：
deadlock.Opts{RLock: true, ReportAll: true}，避免漏报 - 只在测试或开发环境启用，生产环境禁用（它会带来可观的性能开销和 goroutine 状态跟踪负担）
- 注意：启用
RLock: true后，所有sync.RWMutex实例都会被包装，包括第三方库内部使用的——若遇到兼容问题，可改用白名单模式，仅包装你自己的锁字段
网络服务中锁升级场景的典型死锁链
常见于 HTTP handler 中先读缓存（mu.RLock()），再异步触发数据更新（如调用下游 API 后写回），而更新逻辑里又尝试 mu.Lock() ——此时若该 handler goroutine 已持有读锁，mu.Lock() 就会阻塞；而其他等待读锁的 goroutine 全部挂起，因为 RWMutex 内部计数器已被污染。
关键特征是 panic 日志里看不到 fatal error: all goroutines are asleep - deadlock!，而是表现为服务响应延迟飙升、pprof 显示大量 goroutine 卡在 (*RWMutex).Lock 或 (*RWMutex).RLock，且 runtime.NumGoroutine() 持续增长但无实际处理进展。
实操建议：
- 绝不在已持有
mu.RLock()的 goroutine 中调用mu.Lock()；需要升级时，先mu.RUnlock()，再mu.Lock()（并重新校验状态） - 把“读-判断-写”逻辑拆成两阶段：第一阶段只读+生成变更计划，第二阶段单独 goroutine 拿写锁执行；中间用 channel 或
atomic.Value传递计划 - 用
go tool trace查看 goroutine 状态变迁，重点观察是否出现 “SyncBlock → Runnable → SyncBlock” 循环，这是锁升级失败的典型信号
为什么 -race 不报这类死锁
-race 检测的是**数据竞争**（多个 goroutine 无同步地读写同一内存地址），而 RWMutex 读锁重入或锁升级失败属于**逻辑死锁**——所有操作都加了锁，访问是线程安全的，只是锁的使用顺序违反了约束条件。运行时无法从内存访问模式推断出“这里本不该再 RLock”，所以 -race 完全静默。
实操建议：
- 不要指望
-race替代锁行为审查；它和go-deadlock是互补工具，不是替代关系 - 在 CI 中同时跑两类检查：
go test -race+GOFLAGS="-tags=deadlock" go test（需提前在build tags中引入go-deadlock） - 对高频路径上的
RWMutex，手动加注释说明“此处只读”或“允许升级”，避免后续维护者误加写操作
线上服务如何安全启用 go-deadlock
直接替换 sync 包有风险：某些依赖底层调度细节的库（如 net/http 内部连接池）可能因锁包装后行为微变而异常。更稳妥的方式是只包装你可控的业务锁，而非全局替换。
实操建议：
- 定义新类型封装锁：
type SafeRW struct { mu sync.RWMutex }，然后在所有业务代码中用它，而非裸用sync.RWMutex - 在
SafeRW方法中集成go-deadlock检测逻辑，其余地方保持原生行为透明 - 上线前做压测对比：开启前后 QPS、P99 延迟、goroutine 数量变化；重点关注
runtime.ReadMemStats中Mallocs是否激增（锁包装会额外分配对象）
真正难排查的不是报错的死锁，而是那些不 panic、只让服务缓慢退化的锁误用——比如读锁未释放导致写锁饥饿，或者锁粒度太粗让并发吞吐归零。这些不会触发 go-deadlock，也逃过 -race，只能靠 pprof 和 trace 长期观察 goroutine 等待分布。
