因为amqp.Connection.Consume不接受context.Context参数，它返回阻塞channel，无法感知取消信号；需用context控制消费循环启停，配合ch.Cancel、显式Close及sync.WaitGroup确保安全退出。
为什么 context.Context 不能直接传给 amqp.Connection.Consume？
因为 amqp.Connection.Consume（来自 streadway/amqp）本身不接受 context.Context 参数，它返回的是一个阻塞的 <chan amqp.delivery></chan>。一旦开始接收消息，goroutine 就卡在 channel 接收上，无法感知外部取消信号。强行关闭连接或 channel 可能导致消息丢失、panic 或 goroutine 泄漏。
真正需要控制的是「消费循环」和「连接生命周期」——不是让 Consume 自己响应 context，而是用 context 控制它的启动、暂停与终止时机。
实操建议：
- 不要把 context 塞进
Consume调用里（它根本不支持） - 用
context.WithCancel创建可取消的 ctx，在收到退出信号时调用 cancel() - 所有依赖 context 的子 goroutine（如消息处理、重连逻辑）都应监听
ctx.Done() - 连接对象（
*amqp.Connection）和 channel（*amqp.Channel）需显式.Close()，否则资源不会释放
如何安全地停止正在运行的 amqp.Consume 循环？
核心是：用 sync.WaitGroup 管理消费者 goroutine，配合 ctx.Done() 触发退出流程，并确保最后关闭 channel 和连接。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：
— 直接 close(msgs) 导致 range msgs panic
— 忘记调用 ch.Cancel(tag, false)，导致 RabbitMQ 继续投递消息
— 在 ctx.Done() 后仍尝试处理已拉取但未 ack 的消息
实操建议：
- 为每个
Consume调用指定唯一tag string，便于后续ch.Cancel(tag, false) - 在消费循环中用
select同时监听msgs和ctx.Done()，避免阻塞 - 收到
ctx.Done()后，先调用ch.Cancel(tag, false)，再等待当前正在处理的消息完成（如有），最后ch.Close()、conn.Close() - 使用
defer wg.Done()+wg.Add(1)确保主 goroutine 等待消费者退出
示例关键片段：
msgs, err := ch.Consume("queue", consumerTag, false, false, false, false, nil)
if err != nil { return err }
defer func() { _ = ch.Cancel(consumerTag, false) }()
go func() {
defer wg.Done()
for {
select {
case d, ok := <-msgs:
if !ok {
return
}
// 处理 d，注意：此处不应再检查 ctx.Done()，因可能已超时
d.Ack(false)
case <-ctx.Done():
return
}
}
}()
ch.Cancel(tag, noWait) 中 noWait=true 有什么风险？
noWait=true 表示不等待 RabbitMQ 确认取消，立即返回。看起来快，但会掩盖两个关键问题：
- RabbitMQ 可能仍在向客户端推送最后几条消息，而你的代码已关闭 channel，导致
msgschannel 关闭后继续写入 panic - 如果网络延迟高或 broker 负载大，取消请求可能实际失败，但你误以为已生效
所以生产环境应始终用 noWait=false（默认值），并配合超时控制：
- 在调用
ch.Cancel(tag, false)前，先设置一个短超时（如 5s），防止无限阻塞 - 若超时，再考虑强制关闭底层连接（但此时需接受部分消息可能丢失）
- 更稳妥的做法是：取消前先禁用自动 ack（
autoAck=false），确保每条消息都显式 ack/reject，退出时对未处理完的消息做 reject + requeue=false
优雅退出时，未确认（unack）消息怎么处理？
RabbitMQ 默认在 TCP 连接断开时，将 unack 消息重新入队（前提是 requeue=true）。但这不可靠：若连接异常中断（如 kill -9），broker 不一定来得及重入队；且重入队会打乱顺序、增加重复消费概率。
真正可控的方式是主动管理：
- 创建 channel 时设
autoAck=false（必须） - 每条消息处理完后显式调用
d.Ack(false)或d.Nack(false, false, false) - 退出前，对已拉取但尚未处理完的消息，用
d.Nack(false, false, false)拒绝并丢弃（requeue=false），或d.Nack(false, false, true)拒绝并重入队（requeue=true） - 注意：不能在
ctx.Done()后还对d调用 Ack/Nack —— 因为d所属的 channel 可能已被关闭，会 panic
这意味着你需要在消费循环中缓存「正在处理」的消息引用（例如用 map 或 sync.Map 记录 deliveryTag → processing status），并在退出前遍历清理。不过更轻量的做法是：只保证「新消息不再进入」，已拉取的允许超时失败由 broker 处理。
复杂点在于：没有银弹。你要根据业务容忍度选策略 —— 是宁可丢失也不重复，还是宁可重复也要不丢。而这个决策，必须体现在 Nack 的参数里，而不是靠 context 一关了之。
