go-deadlock必须替换sync.Mutex才能生效，因为它是在运行时通过deadlock.Mutex的Lock/Unlock方法记录锁链、等待状态和调用栈来检测死锁，混用则完全失效。
go-deadlock 为什么必须替换 sync.Mutex 才能生效
它不是静态分析工具，而是运行时检测：所有锁操作都走 deadlock.mutex 的 lock() 和 unlock() 方法，内部会记录当前 goroutine 持有的锁链、等待的锁、调用栈及时间戳。一旦发现某个 goroutine 等待某把锁超过 deadlocktimeout（默认 30 秒），就 panic 并打印完整堆栈。
这意味着你不能只在测试里临时换一个变量类型——所有生产代码中用到 sync.Mutex 的地方，都得显式替换成 deadlock.Mutex，否则检测完全不触发。
- 替换不是“加个 wrapper”，而是直接声明为
var mu deadlock.Mutex，且所有mu.Lock()调用都来自该类型 - 如果你混用
sync.Mutex和deadlock.Mutex，后者对前者完全无感知，死锁照样静默发生 - CI 测试阶段启用后，若 panic 出现，说明已真实复现死锁路径，不是误报
如何在单元测试中安全启用 go-deadlock
直接在 main 或 test 文件里全局替换 sync.Mutex 会污染生产行为，正确做法是仅在测试构建标签下有条件注入：
- 在测试文件顶部加
//go:build testdeadlock，并确保go test -tags=testdeadlock运行 - 定义一个可切换的锁类型别名：
type Mutex interface{ Lock(); Unlock() }，测试时用deadlock.Mutex实现，生产用sync.Mutex - 避免在
init()或包级变量中初始化deadlock.Mutex，否则可能被非测试代码意外触发 - 务必设置超时：
deadlock.Opts.DeadlockTimeout = 500 * time.Millisecond，防止测试卡死过久
常见误报和真死锁的区分方式
panic 日志里带 "potential deadlock" 不等于“程序有 bug”，要结合上下文判断：
- 如果 panic 发生在
time.Sleep或select {}后，大概率是测试逻辑没等 goroutine 结束就退出了——这不是死锁，是测试写法错误 - 如果 panic 堆栈显示两个 goroutine 分别卡在
mu1.Lock()和mu2.Lock()，且它们之前已分别持有mu2和mu1，那就是典型的 AB-BA 循环等待，必须修复 - 注意
defer mu.Unlock()是否被 panic 跳过：若 unlock 在 defer 里但 lock 后立即 panic，锁不会释放，后续测试用例可能被阻塞 - 数据库事务里的锁（如
SELECT ... FOR UPDATE）不会被go-deadlock捕获，它只管 Go 层的 mutex/channel，别指望它报 MySQL 1213 错误
容易被忽略的底层细节
死锁检测不是纯应用层问题，很多表现看似“Go 死锁”，实则是数据库配置或 SQL 写法导致的假象。
