go test -race 不能检测死锁，仅识别数据竞争；go-deadlock 需全局替换 sync.mutex 为 deadlock.mutex 并设超时，方能运行时捕获锁循环，但不覆盖 db 层阻塞。
go test -race 不能检测死锁，但必须开
很多人误以为 -race 能报死锁，其实它只抓数据竞争（data race），比如两个 goroutine 并发读写同一个变量。它不感知 channel 阻塞、mutex 持有或 wg.Wait() 卡住。但不开 -race 就可能把“本该唤醒却没唤醒”的竞态问题当成死锁来排查——比如一个 goroutine 因共享变量被覆盖而漏发信号，结果另一个 goroutine 永远等在 上。
- CI 中必须加
go test -race -timeout 30s -count=1 ./，否则竞态漏检率极高 - 常见漏点：
for _, v := range items { go func() { use(v) }() }—— 所有 goroutine 共享最后一个v，修复用go func(v Item) { use(v) }(v) -
-race会略微拖慢测试速度，但比花半天查“假死锁”强得多
pprof/block 是死锁发生前最准的探针
等程序真 panic 出 fatal error: all goroutines are asleep - deadlock! 再动手，往往已错过关键上下文。此时 /debug/pprof/block 能提前暴露阻塞链：它列出所有因 channel、mutex、semaphore 等同步原语而等待超过阈值的 goroutine，含等待时长和调用栈。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 启动时导入
_ "net/http/pprof"，加http.ListenAndServe(":8080", nil)即可访问 - 重点看等待时间 > 2s 的条目：
ch 等了 5s？大概率接收端没启动或已退出 - 生产环境务必限制访问 IP 或加认证，别直接暴露
/debug/pprof/
go-deadlock 必须全局替换 sync.Mutex 才生效
go-deadlock 不是静态扫描器，它靠运行时拦截 Lock()/Unlock() 调用记录锁链。混用 sync.Mutex 和 deadlock.Mutex，后者对前者完全无感，检测形同虚设。
- 测试文件顶部加
//go:build testdeadlock，CI 运行时用go test -tags=testdeadlock - 声明锁类型为
var mu deadlock.Mutex，而非var mu sync.Mutex后 cast - 设置超时：
deadlock.Opts.DeadlockTimeout = 500 * time.Millisecond，防测试卡死 - 别在
init()或包级变量里初始化deadlock.Mutex，避免非测试代码触发
panic 日志里带 "potential deadlock" 不等于 bug
go-deadlock 报的 potential deadlock 需结合堆栈判断：若两个 goroutine 分别卡在 mu1.Lock() 和 mu2.Lock()，且之前已持有对方锁，就是 AB-BA 循环；但若堆栈里有 time.Sleep 或 select {}，大概率是测试没等 goroutine 结束就退出。
-
defer mu.Unlock()在Lock()后 panic 会被跳过，后续测试可能被阻塞 - 数据库锁（如
SELECT ... FOR UPDATE）不会被go-deadlock捕获，它只管 Go 层原语 - 真正难缠的是“伪死锁”：SQL 事务没提交 + 应用层 mutex 错序，表面像 Go 死锁，实则是 DB 层阻塞
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
