RabbitMQ 无原生发送失败回调，需启用 Publisher Confirms 并注册 ConfirmListener 处理 handleAck/handleNack；配合 mandatory=true 与 ReturnListener 捕获路由失败；注意超时、连接中断及幂等性保障。
RabbitMQ 本身不提供“发送失败回调”这种直接的机制，因为消息发送（publish）是异步且无确认的默认行为。要实现类似“发送失败就通知我”的效果，核心在于启用 发布确认（Publisher Confirms），并配合正确的编码逻辑来捕获确认结果——成功或失败（如超时、路由失败、Broker 拒绝等）。
开启 Publisher Confirms 并监听确认结果
这是实现发送反馈的基础。需在 Channel 上启用 confirm 模式，并注册回调监听器：
- 调用
channel.confirmSelect()启用确认模式 - 使用
addConfirmListener()注册ConfirmListener，分别处理handleAck（成功）和handleNack（失败） - 注意：Nack 不仅表示网络断开，也包括消息无法路由（如 exchange 不存在、routing key 匹配不到 queue 且未设置 mandatory）、Broker 内存不足拒绝等场景
正确使用 mandatory 参数 + Return Listener（针对路由失败）
当消息无法被路由到任何队列（例如 routing key 错误、queue 不存在、exchange 类型不匹配），即使开启了 confirm，也可能只收到 Nack；但更明确的方式是结合 mandatory=true 和 ReturnListener：
- 发送时设置
props.setMandatory(true) - 调用
channel.addReturnListener()监听被退回的消息（basic.return） - 该监听器会在消息无法路由时立即触发，比等待 confirm timeout 更及时，适合做快速兜底处理（如记录日志、重发、告警）
避免常见陷阱：超时、连接中断与幂等性
实际生产中，失败往往不是“立刻返回”，而是因网络抖动、Broker 响应延迟导致超时或连接断开：
- confirm 的 ack/nack 可能延迟，建议设置合理的
waitForConfirms(timeout)或用异步 listener 配合本地唯一 message ID 标记状态 - Channel 关闭或连接断开时，未确认消息会丢失——需结合 消息持久化（deliveryMode=2）+ 事务/confirm + 本地消息表 实现可靠发送
- 回调中若触发重发，必须保证消费者端幂等（如用业务 ID 去重），否则可能重复消费
简单示例：带失败回调的发送逻辑
伪代码示意关键流程：
channel.confirmSelect();
channel.addConfirmListener(
seqNo -> log.info("消息已确认: {}", seqNo),
seqNo -> {
// 这里就是你的“发送失败回调”
log.error("消息未确认（Nack）: {}", seqNo);
// 可触发重试、落库、告警等
handleSendFailure(seqNo);
}
);
channel.addReturnListener((replyCode, replyText, exchange, routingKey, props, body) -> {
log.warn("消息被退回 - code:{}, text:{}, routingKey:{}", replyCode, replyText, routingKey);
handleRoutingFailure(routingKey, body);
});
channel.basicPublish(exchange, routingKey, mandatory, props, body); // 发送 
