必须配置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 是 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 抓住它。
