用 github.com/streadway/amqp 是当前最稳的选择，但“可靠”需手动配齐 QueueDeclare、Publish、Confirm 和 Consume 四环节的持久化与确认参数，缺一则消息可能丢失。

直接说结论：用 github.com/streadway/amqp 是当前最稳的选择，但“可靠”不靠框架自动实现，得靠你手动配对 QueueDeclare、Publish 和 Consume 的持久化与确认参数，漏一个就可能丢消息。

为什么默认连接和发布会丢消息

RabbitMQ 默认行为是“尽力而为”——连接断开、服务重启、消费者崩溃，都可能导致消息丢失。Golang 的 amqp 包本身不开启任何可靠性保障，全靠你显式配置。

• amqp.Dial("amqp://...") 建立的是普通 TCP 连接，不带重连逻辑，异常后不会自动恢复
• channel.QueueDeclare 第二个参数设为 false（即非持久化），队列会在 RabbitMQ 重启后消失
• channel.Publish 中没设 mandatory 或没监听 confirm 模式，发出去就“以为成功”，其实可能被拒收或路由失败
• 消费者用 channel.Consume 但没设 autoAck = false，消息一送达就立刻从队列删掉，哪怕处理中途 panic 也来不及补救

必须配齐的四个持久化/确认开关

这四点缺一不可，否则谈不上“可靠”。它们分别控制不同环节的落地保障：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• QueueDeclare(..., true, false, false, false, nil)：第二个参数 true 表示队列持久化（存磁盘），否则重启后队列没了，新消息无处可去
• amqp.Publishing{DeliveryMode: amqp.Persistent}：必须显式设 DeliveryMode 为 Persistent，否则消息体不落盘，只存在内存里
• channel.Confirm(false) 后监听 channel.NotifyPublish：用于捕获 broker 是否接收了 publish 请求，防止网络丢包导致“以为发了，其实没到”
• channel.Consume(..., false, ...)：第四个参数 autoAck 必须为 false，之后用 msg.Ack(false) 手动确认，确保处理完才删消息

常见错误现象与对应修复点

遇到这些情况，基本就是上面某一项漏了：

立即学习“go语言免费学习笔记（深入）”；

• 服务重启后消息全丢 → 检查 QueueDeclare 是否传了 true，以及 Publishing.DeliveryMode 是否为 Persistent
• 消费者 crash 后消息消失 → 确认 Consume 调用中第四个参数是 false，且代码里有 msg.Ack(false)（不是 msg.Nack 或漏写）
• 高并发下部分消息没进队列，也没报错 → 开启 channel.Confirm 并监听 NotifyPublish，检查是否有 confirm.Select 失败或未收到 ack
• 本地测试正常，上生产后频繁断连 → amqp.Dial 不带重试，需自己包装连接逻辑，比如用 backoff.Retry 或简单 for-loop + sleep 重连

不要依赖框架自动兜底

有些封装库（如 go-rabbitmq 或自研 wrapper）会把 autoAck = true 设为默认，或者把 DeliveryMode 隐藏成可选参数。一旦你没细看文档或没覆盖测试场景，上线后就会在低峰期“一切正常”，高峰期突然开始丢单。真正可靠的链路，是每个环节都明确知道谁负责落盘、谁负责确认、谁负责重试——而不是指望某个 SendWithGuarantee() 方法替你扛下所有。