Go语言操作RabbitMQ实现可靠消息传输：语言学习中的中间件应用-Golang-PHP中文网

要保证rabbitmq消息不丢失，必须同时启用生产端confirm机制、broker端exchange/queue/message三层持久化、消费端手动ack与重试，缺一不可。

go语言操作rabbitmq实现可靠消息传输：语言学习中的中间件应用

Go 操作 RabbitMQ 要做到“不丢消息”，光连上、发出去远远不够——必须同时控制好生产端落盘、消费端处理、连接异常这三道关卡。

默认情况下，RabbitMQ 的 Queue 和 Exchange 都是临时的，Broker 重启后就消失。要让它们存活下来，必须显式设置 durable 参数为 true，且所有环节（Exchange、Queue、Binding、消息本身）都要一致启用持久化，否则前功尽弃。

channel.ExchangeDeclare 的 durable 参数必须为 true，否则即使队列持久，路由也会失效
channel.QueueDeclare 的第一个参数 durable 同样必须设为 true；autoDelete 和 exclusive 应为 false，否则无法跨连接复用
Binding 不需要单独设持久化，但必须在 Exchange 和 Queue 都已声明为 durable 后再调用 QueueBind，否则绑定无效

很多人以为给 amqp.Publishing 加上 DeliveryMode: amqp.Persistent 就万事大吉，结果 Broker 崩溃后消息还是没了——因为这只是告诉 RabbitMQ “请存盘”，但没确认它真存进去了。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

关闭自动 Ack 是基础，但很多代码只做了 msg.Ack(false)，却没处理失败路径或资源泄漏，导致消息卡死或重复消费。

务必先调用 channel.Qos(1, 0, false) 限制预取数量，否则大量消息被拉取但未处理完就堆积在 consumer 内存中
业务逻辑出错时，别直接 msg.Nack(false, true) 无条件重入队——可能触发无限循环；应结合死信交换机（DLX）+ TTL 控制重试次数
ACK/NACK 必须在同一个 amqp.Channel 上执行，跨 goroutine 使用需加锁或通过 channel 同步，否则 panic 报 invalid memory address

RabbitMQ 官方 Go 客户端（github.com/rabbitmq/amqp091-go）不自带重连逻辑，自行实现时容易漏掉 Channel 级错误或重复声明资源。

连接级错误（如网络中断）可通过 conn.NotifyClose 监听，但 Channel 关闭需额外监听 channel.NotifyClose
重连后必须重新声明 Exchange、Queue、Binding —— 即使它们是 durable 的，也要再次调用 Declare，否则 Publish/Consume 会报 not found
避免在重连过程中并发调用 channel.Publish，应在新 Channel 就绪后再恢复生产，否则触发 Channel closed panic

真正可靠的链路不是某个函数设个 flag 就能达成的，而是每一步都得对齐 RabbitMQ 的状态模型：Exchange 存在吗？Queue 绑定好了吗？消息进磁盘了吗？消费者真的处理完并 ACK 了吗？少一个环节，就可能在凌晨三点收到告警。