必须配置publisher-confirm-type: correlated，否则spring amqp忽略回调；none彻底关闭确认，simple为同步阻塞且不支持多消息追踪，correlated是唯一推荐的异步可关联模式，需配合publisher-returns: true和mandatory: true保障端到端可靠性。

必须在 Spring Boot 配置中启用 publisher-confirm-type，且不能只靠代码调用 channel.confirmSelect() —— 否则 Spring AMQP 会忽略你的回调设置。

application.yml 必须配置 publisher-confirm-type: correlated

这是开启 Publisher Confirm 的前提，Spring AMQP 不会自动为你开启确认通道，仅靠 Java 代码里调用 channel.confirmSelect() 是无效的（因为 Spring 管理的 RabbitTemplate 会复用或重建 Channel，你的手动设置会被覆盖）。

• none：默认值，完全不启用，setConfirmCallback 注册了也白注册
• simple：启用但仅支持同步阻塞式确认（如 waitForConfirmsOrDie()），无法设回调，且 RabbitTemplate 在调用后会关闭 Channel，不适合持续发消息
• correlated：唯一推荐的选项，允许你传入 CorrelationData 并注册 ConfirmCallback，异步、可追踪、可重试

同时建议配 publisher-returns: true，它和 mandatory: true 配合才能触发 ReturnCallback（即消息没路由到任何 Queue 时的兜底回调）。

RabbitMQ 4.2.3

RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。

下载

RabbitTemplate.setConfirmCallback() 只能设一次，且必须在首次发送前

Spring 官方明确要求：同一个 RabbitTemplate 实例上，setConfirmCallback() 只能调用一次。重复调用会抛 IllegalStateException。

• 推荐在 @PostConstruct 或 @Bean 初始化阶段设置，而不是每次发消息前都设
• 回调函数里拿到的 ack 值为 true，仅代表消息**成功到达 Exchange**，不代表已入队（要入队需配合 publisher-returns + mandatory）
• cause 字段在 ack=false 时可能为空，不要依赖它做精确错误分类

发消息时必须传 CorrelationData，否则回调里收不到上下文

correlated 模式下，不传 CorrelationData 对象，ConfirmCallback 中的 correlationData 参数就是 null，你将无法关联到原始消息（比如重发时找不到原始 payload 或 ID）。

• 简单场景可只传 new CorrelationData(UUID.randomUUID().toString())
• 业务关键消息建议把业务单号、traceId 存进 CorrelationData 的 getFuture() 或自定义字段（需继承扩展）
• 注意：如果用的是 RabbitTemplate.convertAndSend()，需显式传参，不能依赖默认构造

真正容易被忽略的是：即使配置和回调都对了，若 Exchange 不存在、RoutingKey 写错、或绑定关系缺失，ack 仍可能是 true（因消息已抵达 Exchange），但后续就静默丢弃了——这时候得靠 ReturnCallback 抓住它。