Gin中不能直接在handler调用ch.Consume，因其返回阻塞channel会导致HTTP请求卡死且可能panic；正确做法是用独立goroutine启动消费者，并通过context控制生命周期，配合Qos、defer Ack/Nack及errgroup实现优雅退出。
为什么Gin里不能直接调用ch.Consume启动消费者
因为ch.Consume返回的是一个阻塞的<-chan amqp.Delivery，一旦在Gin handler里调用，就会卡死当前goroutine，HTTP请求永远不返回。更糟的是，如果连接断开或队列不存在，ch.Consume可能直接panic，整个服务崩溃。
正确做法是把消费者逻辑抽离到独立goroutine中启动，且必须配合context.Context做生命周期管理——Gin服务重启或SIGTERM信号到来时，能主动关闭channel、Ack未处理完的消息、再断开连接。
- 别在
router.GET里写msgs, _ := ch.Consume(...)；它不是“注册”，是“立刻开始收消息” - 消费者goroutine需监听
ctx.Done()，收到信号后先调msg.Ack(false)（避免重回队列），再ch.Cancel和conn.Close - 若用
amqp.AutoAck: true，消息一送达就丢，Broker不会再重发——业务出错就永久丢失，慎用
amqp.Delivery.Ack被跳过导致消息堆积的常见原因
消费者拿到amqp.Delivery后，必须显式调用msg.Ack(false)才算处理完成。但实际代码里，return、panic、未捕获的err != nil分支，甚至os.Exit(1)都会绕过Ack调用，RabbitMQ会一直把该消息标记为unacked，最终触发流控、拖慢整个队列吞吐。
最稳妥的写法是用defer包裹Ack逻辑，并确保只在成功处理后才Ack：
立即学习“go语言免费学习笔记（深入）”；
func handleDelivery(msg amqp.Delivery) {
defer func() {
if r := recover(); r != nil {
msg.Nack(false, false) // panic时拒绝并重回队列
}
}()
if err := processEmail(msg.Body); err != nil {
msg.Nack(false, true) // 处理失败，拒绝并重新入队
return
}
msg.Ack(false) // 成功才确认
}
-
msg.Ack(false)中的false表示不批量确认，单条处理单条Ack - 别用
msg.Ack(true)批量确认——万一中间某条失败，前面已Ack的也回不去了 - 用
msg.Nack替代Ack时，第二个参数requeue=true会让消息回到队尾；设false则进DLX死信队列（需提前声明）
如何让RabbitMQ消费者支持优雅退出
Gin服务重启时，正在处理的消息若没Ack或Nack，会被RabbitMQ判定为“失联”，默认24小时后放回队列（取决于delivery-limit和message-ttl）。要真正实现优雅退出，必须让消费者goroutine响应os.Interrupt或syscall.SIGTERM，并在退出前清空未处理消息。
关键点不在“快”，而在“可控”：用errgroup.WithContext统一管理所有消费者goroutine，主goroutine退出前等待它们全部结束。
- 启动消费者前，先调
ch.Qos(1, 0, false)限制预取数为1，避免单个消费者积压大量unacked消息 - 消费循环里用
select { case d := ，而不是<code>for d := range msgs - 退出前遍历
msgs通道剩余消息（需用time.After加超时保护），逐条Nack(requeue=false)进DLX
消费者端持久化与重试配置容易漏掉的三项
很多人只关注生产者端的DeliveryMode: amqp.Persistent，却忘了消费者侧同样需要配置才能保证消息不丢。Broker默认不会把消息刷盘，即使队列声明了durable: true，若没配对等参数，重启后消息照样消失。
这三项必须同时生效：
- 队列声明时
durable: true（已知） - 发送时
amqp.Publishing{DeliveryMode: amqp.Persistent}（已知） - 消费者声明队列后，必须调用
ch.ExchangeDeclare(..., durable: true)——哪怕用的是默认""交换机，也要显式声明其持久化属性，否则Broker可能降级为非持久模式
重试不是靠无限循环，而是靠DLX+死信路由：把处理失败的消息发往x-dead-letter-exchange绑定的死信队列，再由另一个消费者做人工干预或降级处理。直接在原消费者里time.Sleep重试，会卡住整个channel。
