Go使用RabbitMQ官方amqp091-go库实现安全发布者确认-Golang-PHP中文网

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)
    }
}