go vet不能检测死锁但能揪出典型诱因：如range未close、select缺default、WaitGroup值传递、defer前panic致锁未释放，这些是死锁高发前置模式。
go vet 不能检测死锁，但能揪出典型诱因
很多人误以为 go vet 能报死锁，其实它只检查可疑模式：比如 range 无关闭、select 缺默认分支、sync.WaitGroup 值传递、defer mu.Unlock() 前 panic 导致锁未释放。这些不是死锁本身，但大概率引发死锁。
-
go vet会警告for v := range ch但没 close 的场景，这是无缓冲 channel 死锁高发区 - 检测到
wg.Add(1)后没配对wg.Done()，或把sync.WaitGroup当参数传进 goroutine（值拷贝），说明 wg.Wait() 永远不会返回 - 发现
mu.Lock()后紧跟panic且没 defer unlock，意味着锁可能永远卡住——后续 goroutine 就会阻塞在mu.Lock()
staticcheck 可识别部分死锁前置模式
staticcheck 比 go vet 更深一层，能发现更隐蔽的逻辑断链。它不模拟执行，而是基于控制流和数据流推断“某条路径下 channel 接收/发送必然缺失”。
- 报
SA5002：检测到for range ch所在函数中，没有任何路径调用close(ch) - 报
SA5008：发现select语句中所有case都是 channel 操作，且无default或timeout，提示“可能永久阻塞” - 报
SA5011：指出sync.Mutex在非导出字段上被嵌入，但未导出Lock/Unlock方法，外部无法正确加锁释放，易导致锁遗漏
go-deadlock 只对显式替换的锁生效，不覆盖原生 sync.Mutex
go-deadlock 不是静态分析工具，它是运行时拦截器，必须主动替换锁类型才能起作用。混用 sync.Mutex 和 deadlock.Mutex 会导致检测完全失效。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 所有要检测的互斥锁必须声明为
var mu deadlock.Mutex，不能写var mu sync.Mutex再强制转换 - 超时阈值需显式设置：
deadlock.Opts.DeadlockTimeout = 200 * time.Millisecond，否则默认 1s，可能掩盖短时阻塞 - 禁止在
init()或包级变量初始化deadlock.Mutex，否则测试启动前就 panic，CI 直接失败 - 日志里出现
potential deadlock不等于 bug——若堆栈含time.Sleep或select {}，很可能是测试提前退出，而非真实循环等待
静态工具都绕不开 runtime 的最终判决
所有静态分析工具都无法替代 fatal error: all goroutines are asleep - deadlock! 这条 panic 日志。它们只能提示“这里容易出问题”，而 runtime 才是唯一权威裁判——只要所有 goroutine 全部 park 在 、<code>mu.Lock()、wg.Wait() 或 select {} 上，且无可唤醒路径，就立刻终止。
立即学习“go语言免费学习笔记（深入）”；
真正容易被忽略的是：静态工具查不到 channel 发送端和接收端跨 package 启动顺序错乱、DB 连接池耗尽导致 sql.Conn 获取阻塞、或 context 被 cancel 后仍继续往已关闭 channel 发数据——这些得靠 /debug/pprof/block 和 panic 堆栈交叉验证。
