go tool trace无法捕获已发生的死锁panic，因其仅适用于程序未panic但推进缓慢的场景；需提前启用pprof和HTTP服务，在panic前通过go tool trace分析chan send/recv阻塞点。
go tool trace 看不到死锁？因为根本没机会运行
看到 fatal error: all goroutines are asleep - deadlock! 时，go tool trace 已经来不及介入——panic 发生后进程立即终止，HTTP server 没机会响应 /debug/trace 请求。它只适用于“卡但没死锁”的场景，比如协程大量阻塞却仍有 runnable goroutine 在轮转。
真正能用 go tool trace 的前提是：程序还没 panic，只是推进缓慢或疑似卡住。这时需提前埋点：
- 代码里加
import _ "net/http/pprof"和go http.ListenAndServe("localhost:6060", nil) - 运行时执行
go tool trace http://localhost:6060/debug/trace?seconds=5 - 在 Web UI 的 “Goroutine” 标签页筛选状态为
chan send或chan receive的协程，点进去看具体卡在哪行ch 或
注意：go tool trace 本身有可观性能开销，缓冲区为 0 的 channel 最容易暴露阻塞点；带缓冲的 channel 卡住可能是“暂时满/空”，得结合 len(ch) 和 cap(ch) 判断是否真卡死。
dlv 调试时 goroutines 命令只显示快照，不是实时监控
VSCode 里断点停住后看不到其他 goroutine，不是配置问题，是 Delve 的行为限制：它只在暂停瞬间抓取所有 goroutine 的状态快照，且默认仅展开当前活跃 goroutine（比如刚 hit 断点的那个）。休眠、阻塞（如 time.Sleep、ch 、mu.Lock()）或已退出的 goroutine 不会自动列出。
必须手动触发查看：
- 在 DEBUG CONSOLE 输入
goroutines，列出全部 ID 和状态（running、waiting、syscall等） - 用
goroutine [id]切换到目标协程，再执行stack看完整调用栈 - 若想查 channel 状态，用
print ch；查 mutex 是否被持有时，用print mu（注意：需确保变量名可见，非局部作用域）
Delve ≥1.21 + DAP 模式才支持完整 goroutine 列表；旧版本可能漏掉部分阻塞态协程。
panic 日志里的 goroutine 堆栈才是第一手证据
运行时抛出 fatal error: all goroutines are asleep - deadlock! 时，会紧接着打印所有 goroutine 的当前堆栈。这不是辅助信息，是唯一可靠的定位依据——别跳过它去翻 pprof 或重跑。
重点盯三类线索：
-
maingoroutine 停在哪？如果卡在ch 或mu.Lock()，说明主流程在等资源 - 其他 goroutine 是否全停在同一种操作？比如多个都卡在
runtime.chansend，但没一个在runtime.chanrecv，那就是发送方没人收 - 有没有 goroutine 卡在
select {}或空for {}？那是逻辑遗漏退出条件，不是资源争用，但一样触发死锁
日志被截断时，加 GODEBUG=schedtrace=1000 运行，每秒输出调度器快照。若长期显示 goroutines: 1 且 runnable: 0，基本可确认全员阻塞。
sync.Mutex 和 sync.RWMutex 的阻塞不会触发 runtime 死锁 panic
sync.Mutex 重入（持有锁时再次 Lock()）或 sync.RWMutex 多次 RLock()，不会导致 all goroutines are asleep panic。因为那个 goroutine 仍处于 running 状态，只是自己卡在 semacquire 上，调度器认为它“还能动”。这类问题得靠 pprof/goroutine?debug=2 或 go tool trace 发现，表现为大量 goroutine 停在 (*Mutex).Lock 或 (*RWMutex).RLock。
典型陷阱：
- 方法 A 中
mu.Lock()后调用方法 B，B 内部又mu.Lock()，且没Unlock()配对 - RWMutex 的
RUnlock()调用次数多于RLock()，破坏内部计数，后续任何Lock()都会永久阻塞 - defer
mu.Unlock()写在if err != nil { return }后面，导致错误路径下锁未释放
这种阻塞不会让 runtime panic，但会让整个程序“看起来像死锁”——所以排查时不能只盯着那句 fatal error，得把 pprof 和 trace 当成常规动作。
