死锁是Go微服务中协作逻辑缺陷的必然结果；无缓冲channel在main中直接发送必导致deadlock panic，因无接收者时goroutine永久阻塞。
Go 微服务里死锁不是偶发故障，而是协作逻辑缺陷的必然暴露——只要 channel 收发没配对、锁顺序不一致、或 goroutine 生命周期没对齐，运行时就会在某个请求路径上精准 panic：fatal error: all goroutines are asleep - deadlock!。它不给你 retry 机会，直接终止进程。
无缓冲 channel 在 main 中直接发送必死
这是微服务启动阶段最常踩的坑：在 main() 函数里初始化一个 make(chan int)，然后立刻写 ch ，没有并发 goroutine 接收。
- 现象：程序启动即卡住，控制台只输出 panic，无日志、无 trace、无 recovery 可能
- 微服务场景特有风险：HTTP handler 里误用无缓冲 channel 做同步（比如等某个异步校验结果），但校验 goroutine 因 panic 或超时未启动，handler 就永远阻塞
- 修复不是加 buffer，而是重构通信契约：发送方必须确保接收方已就绪；更稳妥的做法是用
select+context.Context包裹发送，设 timeout - 示例：
select { case ch <- val: // 成功 case <-time.After(5 * time.Second): return errors.New("timeout sending to channel") }
多个 sender 关闭 channel 的竞态与泄漏
微服务中常见模式：多个 worker goroutine 向同一 chan Result 发送结果，主 goroutine for range ch 消费。一旦关闭时机错位，要么 panic，要么死锁。
- 错误做法：任意一个 worker 在发送完就调
close(ch)—— 其他 worker 再 send 就 panic：send on closed channel - 正确做法：仅由唯一协调者（通常是启动所有 worker 的 goroutine）负责关闭；用
sync.WaitGroup确保所有 sender 完成后再 close - 关键细节：
wg.Add(n)必须在所有go worker()之前执行，不能在循环内漏掉或重复调用 - 更健壮替代：避免
for range ch，改用for { v, ok := <-ch; if !ok { break } }，配合 context 控制退出
sync.Mutex 交叉加锁在 HTTP handler 中隐式成环
微服务里 handler 经常组合调用多个 service 方法，而每个方法内部又持有不同 mutex —— 表面看无关联，实际可能因调用链形成 AB-BA 锁序循环。
立即学习“go语言免费学习笔记（深入）”；
- 典型场景：用户服务
UserSvc.Get()锁userMu，再调支付服务PaySvc.Charge()；后者又锁payMu，再回调UserSvc.Deduct()锁userMu→ 死锁闭环 - 根本解法不是加更多锁，而是破坏「循环等待」：所有涉及多资源操作，统一按固定顺序加锁（如按 struct 字段名排序：
if &muA < &muB { muA.Lock(); muB.Lock() } else { muB.Lock(); muA.Lock() }） - 绝对禁止：在持有 mutex 期间调用外部接口、数据库查询、或任何可能间接触发另一把锁的函数
- 调试技巧：启用
-race编译，它比死锁更早暴露锁竞争；线上环境可用runtime.NumGoroutine()监控异常增长
context.WithCancel 被提前触发导致 wg.Wait 卡死
微服务请求生命周期管理中，context 和 sync.WaitGroup 协同失效是高发死锁源——cancel 提前了，但 wg.Done() 还没执行。
- 现象：主 goroutine 调
cancel()后立即wg.Wait()，子 goroutine 因 select 检测到<-ctx.Done()退出，但 defer wg.Done() 来不及运行 - 原因：cancel 后子 goroutine 可能在 defer 执行前就 return，尤其当逻辑里有 panic 或提前 return 分支
- 修复核心：wg.Done() 必须在 goroutine 入口第一行 defer，且 cancel 调用必须严格晚于所有
go func()启动 - 安全模式：把 cancel 和 wg 封装进结构体，提供
Shutdown()方法，确保 wg.Wait() 在 cancel() 之后、且所有 goroutine 已响应信号
真正难防的不是单点错误，而是多个 goroutine 在不同请求路径上，因 channel 关闭时机、锁获取顺序、context 生命周期三者耦合产生的“概率性死锁”——它往往只在压测或流量高峰时复现，debug 成本极高。微服务里，宁可多一层封装（比如用带超时的 channel wrapper、锁序管理器、context-aware WaitGroup），也不要依赖“这次应该不会出问题”的侥幸。
