微服务环境下不存在“分布式死锁”，go 的 deadlock panic 仅检测单进程内所有 goroutine 不可唤醒等待；所谓“卡住”实为链路阻塞、超时缺失、context 未传递或下游不可用。
微服务环境下根本不存在“分布式死锁”这个东西——Go runtime 的 fatal error: all goroutines are asleep - deadlock! 只作用于单进程内，跨服务的等待不会被 Go 运行时识别为死锁。你遇到的“卡住”，99% 是链路阻塞、超时缺失、context 未传递或下游服务不可用，不是死锁。
看到 fatal error: all goroutines are asleep - deadlock! 就说明问题在本服务内部
这个 panic 只会在当前进程所有 goroutine 全部陷入不可唤醒等待（如无缓冲 channel 发送无人收、wg.Wait() 没人 wg.Done()、mu.Lock() 后再次 mu.Lock()）时触发。它和别的服务完全无关——哪怕下游 HTTP 接口全挂了，只要你的 goroutine 还在等超时、还在重试、还在 select 中 fallback，就不会 panic。
- 如果 panic 日志里
maingoroutine 停在http.Do()或grpc.Dial()，那不是死锁，是网络层阻塞（默认无超时） - 如果停在
ch 或 <code>，立刻检查 channel 收发是否配对、是否有人 close、是否缓冲已满/空 - 如果多个 goroutine 都停在
sync.(*Mutex).Lock，重点查加锁顺序是否一致、是否 defer 忘写Unlock()、是否在持有锁时调用了可能阻塞的外部调用（如 DB 查询、HTTP 请求）
微服务间“假死锁”的真实排查路径
所谓“分布式死锁”，本质是请求链路在某处断开或无限等待：A 调 B，B 调 C，C 卡住不回，A 就一直等。这不是 Go runtime 能检测的，得靠可观测性工具和显式超时。
- 必须给所有出站调用设 context 和超时：
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)，再传给http.NewRequestWithContext或grpc.DialContext - 用 OpenTelemetry 或 Jaeger 查 trace：看 A 到 B 的 span 是否结束、B 到 C 的 span 是否卡在 “CLIENT_SEND” 或 “SERVER_RECEIVE” 状态
- 检查中间件是否漏传 context：比如 Gin 的
c.Request.Context()被丢弃，新 goroutine 用了 background context，导致 timeout 失效 - 别信日志里的 “waiting for response” —— 很可能是下游 panic 后连接没关，客户端 TCP keepalive 还在等 FIN，实际已不可达
pprof 和 trace 在微服务里怎么用才有效
pprof 不是用来查“跨服务卡住”的，而是帮你确认本服务是否真被自己拖垮了。线上服务必须提前埋点，不能等卡住再加。
- 启动时固定加：
import _ "net/http/pprof"+go http.ListenAndServe("localhost:6060", nil) - 卡住时立刻 curl：
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2' | grep -E "(chan|Lock|Wait)"—— 如果大量 goroutine 停在runtime.chansend，说明本服务内部 channel 配对失败；如果都停在net/http.(*Client).do，说明出站调用没设超时 -
go tool trace对微服务有用但代价高：它能暴露 goroutine 在http.Transport.RoundTrip里等连接池、等 DNS 解析，但需手动采集 5–10 秒快照，生产环境慎用
最容易被忽略的三个微服务陷阱
它们看起来像死锁，实则全是设计缺陷，且调试时堆栈毫无提示：
- 全局变量或 init 函数里起 goroutine，依赖另一个服务的 readiness probe 结果 ——
init执行时其他服务还没起来，goroutine 永远等不到信号，但 runtime 不认为这是死锁（因它还在select或time.Sleep） - 用 channel 做服务发现同步（如
ch ），但注册中心返回空列表，channel 没人收，主 goroutine 卡在发送上 - HTTP handler 里用
defer wg.Done()，但wg.Add(1)写在 if 分支里，某些请求路径漏加 ——wg.Wait()永远不返回，而 panic 日志只显示 main goroutine 停在这，不告诉你 wg 计数是 0
真正难的不是定位 Goroutine 停在哪，而是判断“它该不该停”。微服务里所有等待都必须有明确退出条件：超时、cancel、close、error fallback。没有这些，就不是死锁排查，是架构补漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
