死锁定位需用dlv冻结现场：先goroutines -t列出全部协程，再goroutine <id> bt查栈，重点看sync.(Mutex).Lock或sync.(RWMutex).RLock等阻塞锚点。
dlv attach 无法看到 goroutine 阻塞在锁上？
直接 dlv attach 到运行中的 Go 进程，默认不会自动加载 runtime 符号，goroutine 栈可能只显示 runtime.futex 或 runtime.park，看不出具体在等哪个 sync.Mutex 或 sync.RWMutex。这不是 dlv 的 bug，而是 Go 编译器对锁的内联和优化导致符号信息丢失。
必须确保二进制是用 -gcflags="all=-l"（禁用内联）和 -ldflags="-s -w" 之外的完整调试信息编译的；线上环境若已部署，可临时用 dlv exec ./myapp --headless --api-version=2 --accept-multiclient 启动新实例并复现问题，避免 attach 失效。
怎么快速定位死锁时卡在哪几个 goroutine 和哪把锁？
进入 dlv 后，先执行 goroutines 查看全部协程状态，再用 goroutines -u（显示用户代码栈）过滤掉 runtime 内部 goroutine。重点关注状态为 chan receive、semacquire、sync.runtime_SemacquireMutex 的条目。
- 对疑似阻塞的 goroutine 执行
goroutine <id> bt</id>，看栈顶是否出现sync.(*Mutex).Lock或sync.(*RWMutex).RLock - 若栈里只有
runtime.semacquire1，说明锁已被其他 goroutine 持有，需交叉比对：找出所有持有该 mutex 的 goroutine（通常它正停在defer mu.Unlock()前、panic 中断、或被信号中断） - 用
ps -T -p <pid></pid>对照系统线程 ID 和 dlv 中thread输出，确认是否发生 OS 级线程饥饿（如大量 goroutine 争抢同一个 M）
为什么 pprof mutex profile 抓不到死锁现场？
go tool pprof http://localhost:6060/debug/pprof/mutex?debug=1 只统计「曾被阻塞过且已释放」的锁竞争，死锁一旦形成，阻塞 goroutine 永远不会释放锁，因此该 profile 是空的或数据陈旧。它适合查竞争热点，不适用于死锁诊断。
真正有用的组合是：
-
dlv实时抓栈 +goroutines -s blocked（dlv 1.22+ 支持）快速筛选阻塞态 -
go tool trace录制运行时事件，用view trace查看 goroutine 状态跃迁，定位最后执行的 lock/unlock 操作 - 在关键锁操作前后插入
log.Printf("mu.Lock at %s", debug.PrintStack())（仅调试期），配合dlv trace设置条件断点：trace sync.(*Mutex).Lock /path/to/file.go:123
在线上环境用 dlv 调试高并发服务要避开哪些坑？
dlv 本身会启动一个调试 server，占用额外内存与 goroutine，高并发下可能加剧调度压力甚至触发新的死锁。别在生产流量高峰期 attach。
- 务必限制 dlv 的最大连接数：
--accept-multiclient --api-version=2 --headless --listen=:2345 --log --log-output=gdbwire,rpc，避免被未授权客户端连入 - 不要用
continue让程序继续运行——dlv 在 headless 模式下 continue 后可能无法再次中断，建议用ctrl+c中断后手动step或next探查 - 如果服务用了
CGO_ENABLED=1，dlv 可能无法正确解析 C 栈帧，此时bt显示不全，需改用runtime.Stack手动 dump 到文件再分析
死锁往往藏在 defer 和 panic 恢复路径里，比如 defer mu.Unlock() 前发生 panic 导致锁永远不释放——这种 case 必须结合 goroutine <id> regs</id> 看寄存器中 PC 是否落在 unlock 调用前，不能只信栈打印。
