Go协程不会死锁但会无限阻塞，核心是防无限等待；常见卡点为ch.Consume()断连阻塞、无超时下游调用、未Ack/Reject消息；须对单条消息全生命周期设context超时并透传。
死锁本身不会发生——Go 协程不会“死锁”，但会无限阻塞在 channel 接收、锁等待、或 RabbitMQ msg.Ack()/msg.Reject() 调用上，最终表现为协程堆积、内存暴涨、消费停滞。核心不是防“死锁”，而是防“无限等待”。
为什么 consumer goroutine 会无限阻塞？
常见卡点有三个：
-
ch.Consume()返回的在网络中断或 broker 断连后可能永久阻塞（底层 TCP 连接未及时关闭） - 业务逻辑里调用了无超时的数据库查询、HTTP 请求、或未设
context的第三方 SDK - 忘记调用
msg.Ack()或msg.Reject()，且启用了 manual ack 模式，导致 RabbitMQ 持续 hold 住 unacked 消息，后续消息不再推送（尤其当Qos设为 1 时）
给每个消息处理加 context 超时最有效
不要只给连接或 channel 操作加超时，必须对「单条消息的完整生命周期」设限。关键是在启动协程时传入带 deadline 的 context.Context：
func consumeOneMessage(msg amqp.Delivery, timeout time.Duration) {
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()
<pre class="brush:php;toolbar:false;">// 把 ctx 透传给所有下游调用：DB.QueryContext、http.NewRequestWithContext、cache.GetWithCtx 等
err := processWithContext(ctx, msg.Body)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
msg.Nack(false, true) // 拒绝并重新入队（谨慎！需幂等）
return
}
msg.Reject(true) // 丢弃或进死信（按策略）
return
}
msg.Ack(false)}
- 超时时间建议设为业务 P99 处理时长的 2–3 倍，例如正常耗时 800ms，设
2s；避免过短导致频繁重试，过长加剧积压 - 拒绝重入队（
Nack(requeue=true)）前务必确认业务幂等，否则可能形成无限循环重试 - 不要在超时后还继续执行 DB commit 或发通知——
ctx.Done()后所有依赖该 ctx 的操作应立即中止
channel.Consume() 阻塞必须用 goroutine + select 包裹
ch.Consume() 是同步阻塞调用，一旦底层连接异常，它不会返回，协程就卡死。必须把它放进独立 goroutine，并用 select 控制生命周期：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
go func() {
for {
select {
case <-done: // 外部控制信号，如服务关闭
return
default:
msgs, err := ch.Consume(
"task_queue", "", false, false, false, false, nil,
)
if err != nil {
log.Printf("Consume failed: %v", err)
time.Sleep(1 * time.Second) // 避免疯狂重连
continue
}
for msg := range msgs {
go consumeOneMessage(msg, 2*time.Second)
}
}
}
}()
- 不能把
for msg := range msgs放在顶层 for 循环里——range 本身会阻塞，出错无法退出 - 每次
ch.Consume()失败后要 sleep，否则 CPU 打满且触发 RabbitMQ 连接风暴 -
donechannel 用于优雅停机：收到信号后关闭 channel，所有正在运行的consumeOneMessage会在下一轮select中检测到ctx.Done()并退出
协程泄漏比消息积压更危险，得盯紧 runtime.NumGoroutine()
协程不会自动回收，一个卡住的协程就是一块持续增长的内存。上线后必须监控：
- 定期打点
runtime.NumGoroutine()，突增 > 300% 就告警 - 用
pprof抓取 goroutine stack：curl http://localhost:6060/debug/pprof/goroutine?debug=2，搜amqp.Delivery或select查卡点 - 禁止在 consumer 内部 spawn 不受控的 goroutine（比如忘加
defer cancel()的子 context）
真正难的不是加超时，而是确认每一条路径都尊重了 context 取消信号——尤其是嵌套调用和第三方库。漏掉一处，整条链就悬在那里不动。
