RabbitMQ发布确认机制通过confirm模式+回调确保消息抵达Broker，需配合持久化三件套才可靠，推荐异步confirm并自行管理未确认状态。

RabbitMQ 的发布确认机制（Publisher Confirm）是防止消息在生产者到 Broker 传输过程中丢失的核心手段。它不是“发完就不管”，而是让生产者明确知道每条消息是否已被 RabbitMQ 成功接收并持久化。要真正起作用，需配合正确配置和业务逻辑处理，不能只开启不监听。

开启 confirm 模式并设置回调

这是基础动作。生产者需将信道（Channel）置为 confirm 模式，并注册 ACK/NACK 回调函数：

• 调用 channel.confirmSelect() 启用 confirm 模式；
• 注册 addConfirmListener，实现 handleAck（成功）和 handleNack（失败）两个方法；
• 每条消息会自动分配一个递增的 deliveryTag，回调中通过它关联原始业务消息（建议发送时携带唯一 ID，如 UUID 或订单号）。

区分两种确认粒度：普通 vs 异步

普通 confirm 是同步阻塞式——发一条等一条回执，吞吐低，仅适合调试或极低频场景；实际推荐异步 confirm：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 消息批量发出，不等待单条响应，靠回调异步处理结果；
• 避免线程阻塞，提升并发能力；
• 需自行维护未确认消息的状态（如内存缓存 + 超时重发），防止回调延迟或丢失导致漏处理。

结合持久化使用才真正可靠

confirm 只保证消息到达 Broker 并被接收，但不保证重启后还在。必须搭配“持久化三件套”：

• 交换机声明时设 durable=true；
• 队列声明时设 durable=true；
• 发送消息时设 deliveryMode=2（即 MessageDeliveryMode.PERSISTENT）。

缺一不可。例如只开 confirm 但消息未设持久化，Broker 收到后存在内存里，宕机就丢。

避免常见陷阱

很多问题出在细节疏忽：

• 没关闭自动确认（autoAck=true）——那是消费者端的事，和发布确认无关，但常被混淆；
• 回调中只打印日志，没做重试或落库记录——NACK 到了等于白来；
• 未对超时未回调的消息做兜底（比如 30 秒没收到 ACK 就触发重发）；
• 误用事务（txSelect）替代 confirm——事务性能差、阻塞严重，生产环境应禁用。