分布式死锁需主动监控而非依赖go runtime：通过opentelemetry自定义resource.held/resource.waiting_for属性实现闭环分析，数据库设秒级lock_timeout并类型断言捕获死锁错误重试，grpc调用必带deadline。
Go 微服务里死锁不是 runtime 报 fatal error: all goroutines are asleep 就完事了
分布式场景下，Go 本身的死锁检测只管单进程内 goroutine 阻塞，对跨服务、跨数据库事务、跨消息队列的循环等待完全无感。你看到服务卡住、请求堆积、pprof 显示大量 goroutine 停在 select 或 chan receive，大概率是分布式死锁——但 Go runtime 不会告诉你。
真正要命的是：它不报错，只沉默。你查日志没异常，查 CPU 不高，查内存不涨，最后发现是 A 服务等 B 服务回执，B 服务卡在等 C 服务的 DB 行锁，C 服务又在等 A 服务发来的 MQ 消息……三节点闭环，谁都不动。
- 典型诱因：
context.WithTimeout忘设、DB 事务没配lock_timeout、MQ 消费者没做幂等+重试上限、gRPC 调用未带 deadline - 别指望
go tool trace自动标出跨进程依赖——它连本地 goroutine 调度都得手动抓，更别说跨网络链路 - 用
runtime.Stack打印所有 goroutine 状态？只能帮你确认“卡在哪一行”，无法还原“为什么卡”
用 OpenTelemetry + 自定义 Span 属性标记资源持有与等待点
光埋点没用，关键是要让每个 Span 明确声明：“我持有了什么”和“我在等什么”。OpenTracing 已停更，直接上 OpenTelemetry，但默认 Span 不含资源语义，得自己加。
比如一个扣减库存操作，不能只打 inventory.deduct，而要在 Span 上写死两个属性：
立即学习“go语言免费学习笔记（深入）”；
span.SetAttributes(
attribute.String("resource.held", "db:inventory_items:1001"),
attribute.String("resource.waiting_for", "mq:order_created:20240517-8892"),
)这样在 Jaeger 或 Grafana Tempo 里就能按 resource.held 和 resource.waiting_for 做交叉分析，跑个简单 SQL 就能揪出循环依赖：
- 查所有
resource.waiting_for值匹配db:inventory_items:1001的 Span → 找到谁在等这行库存 - 再查这些 Span 对应的
resource.held→ 看它们各自占着啥资源 - 如果其中某个 Span 的
resource.held正好是另一个 Span 的resource.waiting_for，闭环成立
注意：属性值必须可索引（避免用 JSON blob），且命名规范统一，否则查询失效。别用 held_key 这种模糊字段名，就用 resource.held。
数据库层强制设置 lock_timeout 并捕获 ERROR: deadlock detected
PostgreSQL 默认不主动检测死锁，直到超时才报错；MySQL 的 innodb_lock_wait_timeout 默认 50 秒，太长。微服务里这个值必须压到秒级，否则上游早超时熔断了，DB 还在傻等。
在 sql.Open 后立刻执行初始化语句：
_, _ = db.Exec("SET lock_timeout = '3s'")
// 或 MySQL：
_, _ = db.Exec("SET innodb_lock_wait_timeout = 3")然后所有事务必须显式处理死锁错误：
- PostgreSQL 错误码是
40P01，错误信息含deadlock detected - MySQL 是
ERROR 1213 (40001): Deadlock found when trying to get lock - 别用
strings.Contains(err.Error(), "deadlock")—— 用pgx.ErrCode或mysql.MySQLError类型断言，更稳 - 捕获后立即重试（最多 2 次），别往上抛。重试前加
time.Sleep(10 * time.Millisecond)，错开竞争窗口
gRPC 客户端必须传 context.WithTimeout，且 timeout
很多人只在 handler 入口设一次 context timeout，但 gRPC 调用本身没设，结果上游等 30 秒才放弃，下游 DB 却只等 3 秒就报死锁——上游还在等，下游已释放锁又重试，彻底乱套。
正确做法是：每次 client.SomeMethod(ctx, req) 的 ctx 必须是新派生的，且 timeout 值严格小于下游服务的最短超时项：
- 若下游 DB 设了
lock_timeout = 3s，gRPC 调用 timeout 最多设2.5s - 若下游还调 MQ，而 MQ broker 超时是 1s，则再往下压到
800ms - 别复用 handler 的原始
ctx，尤其别用context.Background()—— 这等于放弃超时控制 - 用
grpc.Dial时开启WithBlock()？别。它会让连接卡住，破坏超时传递
复杂点在于：不同下游超时策略可能不一致，需要服务间约定 SLA 并反向推导客户端 timeout。没人替你算，得写进接口文档，也得写进单元测试的 mock 超时分支里。
