Go中consumer端必须设autoAck=false才能手动Ack，否则RabbitMQ发完即删消息；需配合channel.Ack()/Nack()、Qos预取控制、publish确认模式及持久化配置保障可靠性。
Go 中 consumer 端必须设 autoAck=false 才能手动 Ack
默认情况下，amqp.Consume 的 autoAck 参数为 true，RabbitMQ 一发完就删消息，根本不管消费者是否处理成功。这在生产环境等于裸奔——哪怕消费逻辑 panic 或进程崩溃，消息也永远消失了。
正确做法是显式传入 false，并手动调用 channel.Ack() 或 channel.Nack()：
msgs, err := channel.Consume(
queueName,
"", // consumer tag
false, // autoAck = false ← 关键
false, // exclusive
false, // noLocal
false, // noWait
nil, // args
)
if err != nil {
log.Fatal(err)
}
for msg := range msgs {
// 处理业务逻辑
if err := process(msg.Body); err != nil {
// 失败时拒绝并重新入队
msg.Nack(false, true) // requeue=true
continue
}
// 成功则确认
msg.Ack(false)
}
-
msg.Ack(false)：只确认当前这条消息；设为true表示批量确认所有 ≤ 当前deliveryTag的未确认消息（需保证 deliveryTag 严格递增） -
msg.Nack(false, true)：拒绝当前消息并重新入队；requeue=true是防止消息丢失的底线配置 - 如果业务处理耗时较长，记得在
channel.Qos()中设置prefetchCount=1，避免 RabbitMQ 过度预推消息导致堆积或重复分发
deliveryTag 是每个 channel 独立维护的 64 位整数
你不能跨 channel 复用 deliveryTag，也不能把它存到数据库里跨进程确认——它只在当前 TCP 连接的这个 channel 内有效。一旦 channel 关闭或连接断开，所有未确认的 deliveryTag 就失效了，RabbitMQ 会自动把对应消息标记为 unacked 并可能重发。
常见错误是把 deliveryTag 当作全局唯一 ID 存储或日志追踪，结果发现重启后无法对齐状态。实际应依赖业务自身的幂等 key（比如订单号、事件 ID）做去重，而不是靠 deliveryTag。
另外，multiple=true 的批量确认必须满足两个条件：一是这些消息的 deliveryTag 连续；二是你确认的是“所有 ≤ 某个值”的消息——RabbitMQ 不校验你是否真的收到了它们，全靠你自己逻辑保证顺序和完整性。
生产端要用 channel.Confirm() 配合 NotifyPublish()
consumer 端的手动 Ack 只管“消息被消费了没”，不解决“消息发没发到 RabbitMQ”这个问题。如果网络抖动、交换器不存在、路由失败，basicPublish() 依然会静默返回成功。
必须开启发布确认模式：
err := channel.Confirm(false) // 开启 confirm 模式
if err != nil {
log.Fatal(err)
}
// 启动异步通知监听
confirms := channel.NotifyPublish(make(chan amqp.Confirmation, 1))
go func() {
for conf := range confirms {
if !conf.Ack {
log.Printf("消息投递失败，deliveryTag=%d", conf.DeliveryTag)
// 这里应重试或落库待补偿
}
}
}()
// 发送消息
err = channel.Publish("", queueName, false, false, amqp.Publishing{
ContentType: "application/json",
Body: []byte(`{"id":123}`),
})
if err != nil {
log.Fatal(err)
}
-
channel.Confirm(false)表示非等待模式（即异步），阻塞模式（true）会严重拖慢吞吐，不推荐 -
NotifyPublish返回的是无缓冲 channel，务必另起 goroutine 消费，否则 publish 调用会卡住 -
Confirmation结构体里的DeliveryTag和 consumer 端的不是同一个值，它是 publisher 端独立生成的序列号，仅用于匹配本次 publish 是否落地
不要用事务（txSelect），也不要混用 autoAck=true 和手动 Ack
事务模式在 Go 的 streadway/amqp 包中虽有 channel.Tx()，但它是完全阻塞的：每发一条消息都要等 broker 返回 txCommit 响应，QPS 直接砍掉 90% 以上。所有权威文档和生产实践都明确反对使用。
另一个高频陷阱是：代码里写了 msg.Ack()，但 Consume 时却传了 true。这时 RabbitMQ 根本不会等你调用 Ack，消息早已删除，msg.Ack() 调用会直接 panic 报错 "channel error: not ack'ed"。
真正可靠的链路是两端分离控制：生产端用 Confirm() + NotifyPublish() 保发送，消费端用 autoAck=false + Ack()/Nack() 保处理，中间再加持久化队列（durable=true）和持久化消息（deliveryMode=2）。少一个环节，可靠性就断一截。
