PublishWithDeferredConfirm 默认静默失败，因 dc.Wait() 仅返回布尔值且不自动阻塞，若未调用 WaitError(ctx) 配合超时上下文，将无法捕获如交换机不存在等具体错误，导致确认丢失或 goroutine 泄漏。
直接启用 channel.confirm(false) 并调用 channel.publishwithdeferredconfirm 就能实现安全的发布者确认，但多数人卡在确认失败无感知、上下文超时丢失、或误用共享 channel 导致 panic —— 这些不是库的问题，而是确认流程没闭环。
为什么 PublishWithDeferredConfirm 会静默失败
默认情况下，PublishWithDeferredConfirm 返回的 dc 对象不会自动阻塞，也不绑定任何错误传播机制。如果 RabbitMQ 拒绝消息（比如交换机不存在、mandatory=true 但无匹配队列），dc.Wait() 会返回 false，但没人监听这个结果。
-
dc.Wait()只返回布尔值，不带错误详情；需配合dc.WaitError()才能拿到具体原因 - 若未显式调用
Wait()或WaitError()，确认状态永远不会被消费，goroutine 泄漏风险高 - 没有上下文控制时，
Wait()可能永久阻塞（例如网络中断后服务端未发 confirm/nack）
如何用 context 控制确认超时并捕获真实错误
必须把 WaitError() 和 context.WithTimeout 组合使用，否则无法区分“超时”和“拒绝”。WaitError() 内部已支持上下文，但需手动传入。
- 不要写
dc.Wait()，改用dc.WaitError(ctx) - ctx 必须是带超时的新 context，不能复用发布用的 ctx（后者可能早已 cancel）
- 错误类型可能是
*amqp.Error（如amqp.NotFound），也可能是context.DeadlineExceeded
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
err := dc.WaitError(ctx)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Printf("confirm timeout for msg %s", msgId)
} else if amqpErr, ok := err.(*amqp.Error); ok {
log.Printf("broker rejected: %s (%d)", amqpErr.Reason, amqpErr.Code)
}
}
Channel 不是并发安全的，确认逻辑必须绑定到创建它的 goroutine
常见反模式：一个 Channel 被多个 goroutine 同时用于 PublishWithDeferredConfirm 和 WaitError —— 这会导致帧错乱、panic 或确认丢失。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 每个发布 goroutine 必须独占一个
Channel（即conn.Channel()后不再共享） - 不能把
Channel存在全局变量或 worker pool 中复用 - 如果要用连接池，池里存的是
*amqp.Connection，每次取连接后立即调.Channel()创建新通道
确认失败后重试要避免重复投递
确认失败 ≠ 消息未到达 Broker。它可能已入队但确认帧丢失，也可能根本没发出去。盲目重试会导致重复。
- 对幂等性要求高的场景，必须在消息体中加入唯一 ID（如 UUIDv7 或时间戳+随机数）
- Broker 端需配合启用
publisher_confirms+delivery_mode=2（持久化） - 重试前检查是否已存在同 ID 消息（例如通过死信队列 + 唯一索引插件，或业务层去重表）
最易被忽略的一点：确认失败时，dc 对象本身不可重用。下次发布必须新建 PublishWithDeferredConfirm 调用，不能对旧 dc 多次调 WaitError。
