优先用 github.com/rabbitmq/amqp091-go + go-rabbitmq（boot.dev 维护），因其内置连接池雏形、自动重连、流控和 tcp 阻塞恢复，api 干净且适配 go 1.21+ context 取消语义；streadway/amqp 已归档，新库修复了 context 超时未传播、tls 配置模糊等问题，迁移成本低。
直接上结论：别自己从零封装，优先用 github.com/rabbitmq/amqp091-go + go-rabbitmq（Boot.dev 维护）——它已内置连接池雏形、自动重连、流控和 TCP 阻塞恢复，且 API 干净，适配 Go 1.21+ context 取消语义。
为什么不用 streadway/amqp？
该库已于 2024 年归档，不再接受 PR；新 SDK amqp091-go 是 RabbitMQ 官方推荐，修复了旧库中多个 context 超时未传播、TLS 配置模糊、错误码不统一的问题。迁移只需改 import 和少数函数名（如 amqp.Dial → amqp091.Dial），无逻辑变更。
- 旧库的
Connection.NotifyClose回调在连接闪断时可能漏触发；新库用Connection.NotifyClosed+context.WithTimeout更可靠 -
streadway/amqp的Channel.Publish不支持context.Context，发消息卡死无法主动取消；amqp091-go提供Channel.PublishWithContext - 所有 error 类型现在都实现了
Unwrap()，可精准判断是否为网络中断（errors.Is(err, net.ErrClosed)）
如何让连接“真正自动重连”？
自动重连不是开个 goroutine 循环 dial 就完事——关键在于重连时机、状态同步、未确认消息兜底。用 go-rabbitmq 时，只需传入配置：
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
cfg := &rmq.Config{
URL: "amqp://user:pass@rabbit:5672/%2F",
MaxRetries: 5,
RetryDelay: 2 * time.Second,
ConnectionOptions: amqp091.Config{
Dial: amqp091.DialConfig{ // 支持自定义 net.Dialer
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
},
},
}
client, _ := rmq.New(cfg)
- 重连只在
Connection.NotifyClosed触发后启动，避免误判瞬时抖动 - 重连成功后，会自动重建所有已声明的队列、交换机、绑定关系（需你提前注册
OnReconnect回调） - 未 ACK 的消息不会丢失：客户端内部缓存 unacked 消息 ID，在重连后通过
basic.recover重新投递（前提是队列设了durable=true）
连接池怎么搞才不踩坑？
RabbitMQ 协议本身不支持“连接复用”，所谓连接池，其实是管理多个 *amqp091.Connection 实例，并按需分配给生产者/消费者。但注意：通道（*amqp091.Channel）不能跨 goroutine 复用，所以池化对象必须是连接，而非通道。
- 不要池化
Channel：AMQP channel 不是线程安全的，强行复用会导致channel error: 541 PRECONDITION_FAILED - 池大小建议 ≤ 5：RabbitMQ 单连接承载 100+ channel 是常态，盲目扩连接数反而增加服务端 fd 压力
- 用
sync.Pool管理Channel实例可行，但需确保每次 Get 后调用Channel.Confirm或Channel.Qos重置状态，否则可能继承前一次的 QoS 限制 - 更稳妥的做法是：每个业务 goroutine 自己建 channel，连接由
go-rabbitmq内部池管理——它默认启用连接复用与懒加载
最常被忽略的持久化链路断裂点
标了 DeliveryMode: amqp091.Persistent 还丢消息？大概率是以下三处没对齐：
- 队列声明时
durable参数必须为true（ch.QueueDeclare("q", true, ...)），否则重启后队列消失，持久消息无处落盘 - 若用了自定义 exchange（非默认
""），声明时也得设durable: true，否则路由元数据丢失 - 消费者必须显式关闭 channel 并调用
msg.Ack(false)，不能依赖 autoAck；autoAck=true 时消息一发就删，宕机即丢
真正的“至少一次”交付，需要这三者全部开启，缺一不可。自动重连只是让链路活下来，持久化才是让消息活下来。
