消息重复是At-Least-Once语义的固有特性，publisher-confirm-type和mandatory仅保障投递可达性，不控制消费阶段重试；幂等必须由消费端通过全局唯一且跨重试不变的messageId+Redis实现。
Spring Boot整合RabbitMQ时，消息重复投递是「至少一次（At-Least-Once）」语义下的必然现象，无法靠关闭重试或禁用confirm来根除——必须在消费端做幂等控制。
为什么publisher-confirm-type和mandatory不能防重复？
这两个配置只解决「消息是否送达Broker」和「是否被路由到队列」的问题，不干预后续行为。即使生产者收到ack，若消费者ACK途中网络中断、进程崩溃或超时未响应，RabbitMQ仍会重新入队该消息。这是设计使然，不是bug。
常见错误认知是：开了confirm + 持久化 = 不会重复。实际上，这两者只保「不丢」，不保「不重」。
-
publisher-confirm-type: correlated仅确保消息进了交换机，不保证进队列后不被重发 -
mandatory: true只让路由失败的消息走ReturnCallback，和消费阶段的重复无关 - 消费者手动
ack只是延迟删除消息，但一旦没发出去，就触发重投
必须在消费端校验messageId并写入Redis
RabbitMQ原生支持messageId字段（需生产者显式设置），它是天然的幂等键。消费者拿到消息后，应先查Redis是否存在该messageId，存在则直接跳过，否则处理+写入。
注意几个关键点：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 生产者必须调用
MessagePropertiesBuilder.setMessageId()，不能依赖RabbitMQ自动生成（默认不生成） - Redis key建议带业务前缀+
messageId，如mq:order:create:{{messageId}}，避免跨业务冲突 - 过期时间设为业务最大处理窗口的2–3倍（例如订单处理最长5分钟，Redis TTL设为15分钟）
- 写入Redis和业务DB要放在同一事务里（或用本地消息表+定时补偿），否则可能Redis写了但DB失败，导致漏处理
别忽略死信队列对重复判定的干扰
如果配置了死信队列（DLX）+ 最大重试次数，一条失败消息可能被反复投递N次再进死信。此时Redis里只会存第一个messageId，后续重试消息因ID相同全被过滤——看似幂等，实则掩盖了真实失败原因。
正确做法是：在重试逻辑中保持messageId不变（不要每次重发都生成新ID），同时记录重试次数到消息头（headers.put("x-retry-count", count)），并在消费逻辑中打印该值，便于排查是偶发失败还是持续异常。
否则你看到日志全是「已存在messageId，跳过」，却不知道这条消息其实已经重试了8次都没成功。
真正难的不是加Redis判断，而是把messageId贯穿生产、传输、存储、消费全链路，并确保它在任何重试、转发、死信场景下都不变——这点稍有疏忽，幂等就形同虚设。
