本文详解使用 streadway/amqp 库时，RabbitMQ 生产者在连接中断后重建 Connection 和 Channel 时必须重新启用发布确认（Confirm）模式，否则 NotifyPublish 将无法接收确认消息。
本文详解使用 streadway/amqp 库时，rabbitmq 生产者在连接中断后重建 connection 和 channel 时必须重新启用发布确认（confirm）模式，否则 `notifypublish` 将无法接收确认消息。
在 Go 中使用 RabbitMQ 的 streadway/amqp 客户端实现高可用生产者时，一个常见误区是：仅重建连接（Connection）和通道（Channel），却忽略了通道级别的状态重置。尤其当启用了发布确认（Publisher Confirms）机制时，Channel.Confirm() 是一个一次性、通道级的显式启用操作——它并非连接属性，也不会自动继承到新创建的 Channel 实例中。
原始代码在第 10 次循环后执行了以下操作：
Channel.Close() Connection.Close() // ... 重连 ... Connection, Channel, err = setup(url) // 新连接 + 新 Channel confirms = Channel.NotifyPublish(make(chan amqp.Confirmation, 1))
但关键遗漏在于：未对新 Channel 再次调用 Channel.Confirm(false)。由于新 Channel 默认处于“非确认模式”，即使你注册了 NotifyPublish，RabbitMQ 也不会向该通道发送任何确认帧，导致
✅ 正确做法是在每次成功创建新 Channel 后，立即且显式地启用确认模式：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
// 重连成功后，务必补上这一行！
if err := Channel.Confirm(false); err != nil {
log.Fatalf("failed to enable confirm mode on new channel: %v", err)
}
confirms := Channel.NotifyPublish(make(chan amqp.Confirmation, 1))完整修复后的重连逻辑示例如下：
if i == 10 {
// 安全关闭旧资源
if Channel != nil {
Channel.Close()
}
if Connection != nil {
Connection.Close()
}
// 重试建立连接与通道
var retry int
for retry < 5 {
Connection, Channel, err = setup(url)
if err == nil {
// ✅ 关键：为新 Channel 启用 Confirm 模式
if err := Channel.Confirm(false); err != nil {
log.Printf("warn: confirm.select failed on retry %d: %v", retry, err)
retry++
continue
}
confirms = Channel.NotifyPublish(make(chan amqp.Confirmation, 1))
log.Println("✅ Reconnected and confirm mode re-enabled")
break
}
log.Printf("retry %d failed: %v", retry, err)
time.Sleep(time.Second * 2)
retry++
}
if err != nil {
log.Fatal("failed to reconnect after retries")
}
}⚠️ 注意事项：
- Channel.Confirm() 必须在 Channel.NotifyPublish() 之前调用，否则通知通道将无法绑定确认事件；
- 每个 amqp.Channel 是独立的 RPC 会话，其所有语义（包括 confirm、QoS、事务等）均需单独配置；
- 生产环境建议封装重连逻辑为可重入函数，并加入指数退避（exponential backoff）、最大重试次数及健康检查；
- 若使用 Channel.Publish() 发送持久化消息，请确保 Exchange 和 Queue 已声明、Routing Key 有效，否则 confirmed.Ack 可能为 false，需结合日志与 confirmed.Reason 进一步诊断。
总结：AMQP 通道不具备状态延续性。断线重连 ≠ 简单复用旧逻辑。每一次新建 Channel，都是一次全新的协议会话初始化——Confirm 模式必须显式、主动、及时地重新开启。 这是保障发布确认机制可靠工作的底层前提。
