gin中不能在http handler内直接写rabbitmq消费逻辑，因为handler生命周期极短，响应写出后连接可能立即复用或关闭，而ch.consume()是长连接阻塞监听，放在此处会导致卡死或被中断引发amqp.error{code:541}；正确做法是在main()中用独立goroutine启动消费者，绑定全局复用的connection和channel，autoack设为false，并为每条消息启用带超时的goroutine处理，手动ack/nack确保可靠性。
为什么 Gin 里不能直接写 RabbitMQ 消费逻辑
因为 Gin 的 HTTP handler 生命周期极短，响应一写出就可能复用或关闭底层连接；而 ch.Consume() 是长连接、阻塞式监听，一旦放在 handler 里执行，要么卡死整个请求，要么被调度器强行中断导致 amqp.Error{Code: 541} 或静默退出。这不是“回调”，是“撞线”。
ch.Consume() 必须在应用启动时单独 goroutine 启动
消费者不是随请求触发的回调，而是常驻服务进程里的独立监听者。正确姿势是：在 main() 或初始化函数中，用 go func() {...}() 启动，且必须绑定全局复用的 *amqp.Channel 和 *amqp.Connection。
-
autoAck必须为false：传ch.Consume(queue, "", false, false, false, false, nil)，否则消息一推就删，业务 panic 也收不到 - 每次
delivery都要起新 goroutine 处理，避免阻塞后续消息；但需用context.WithTimeout(ctx, 30*time.Second)控制单条超时 - 不要在
for range msgs外写defer msg.Ack()——msg是循环变量，所有 defer 最终都作用于最后一次迭代的值 - 处理前拷贝 body：
data := append([]byte(nil), msg.Body)，防止后续迭代覆盖内存
手动 Ack/Nack 的边界和陷阱
msg.Ack(false) 和 msg.Nack(false, true) 不是“可选操作”，而是消费链的生死开关。出错不 Nack 就等于丢任务；乱 Ack 就等于伪造成功。
- 业务逻辑执行完、DB 写入成功后，才调
msg.Ack(false) - 任何 error（包括 DB 超时、网络失败、JSON 解析 panic）都该走
msg.Nack(false, true)，requeue=true是防丢底线 -
deliveryTag是 per-channel 单调递增整数，跨 goroutine 或 channel 复用会触发PRECONDITION_FAILED - unknown delivery tag - 多个 consumer goroutine 共享一个
ch时，msg.Ack()必须加锁或改用单 goroutine 模式
如何让消费失败可追溯、可重试
RabbitMQ 本身不记录“为什么失败”，只管投递和确认。要实现可观测重试，得靠外围设计。
- 在
Nack前记录日志，至少包含msg.MessageId、msg.RoutingKey、错误类型和堆栈 - 避免无限重试：可在消息 header 加
retry-count，每次Nack前递增，超过阈值转存 dead-letter queue - 不要依赖
msg.MessageId做业务去重或状态回查——它由生产者设置，RabbitMQ 不校验唯一性，也不保证传递一致性 - 真正可靠的“已处理”状态，应落库（如 PostgreSQL 表
task_status），ACK 前先INSERT ... ON CONFLICT DO NOTHING
最易被忽略的点：consumer 启动时没检查队列是否已声明，或声明时 durable 参数不一致，会导致消息进黑洞——队列名一样，但其实是两个不同生命周期的队列。
