retrytemplate仅作用于消费者端，需显式绑定到simplerabbitlistenercontainerfactory；发送端重试须单独配置rabbittemplate的retrytemplate，并配合publisher-confirm；max-attempts表示总执行次数，recoverer必须指定以防死循环。
重试不是发消息失败时用的，而是消费失败时内部重试
很多人一看到 RetryTemplate 就去配在 RabbitTemplate 发送端，结果发现重试根本不触发——因为 RetryTemplate 在 Spring AMQP 里默认只作用于消费者（@RabbitListener 方法），不作用于生产者发送逻辑。发送失败重试得靠 RabbitTemplate 自己的 setRetryTemplate() 手动设置，且需配合 publisher-confirm 和异常捕获逻辑，和消费端是两套体系。
配置 RetryTemplate 时必须绑定到 listener 容器工厂
Spring Boot 的自动配置不会把你的 RetryTemplate bean 自动注入监听器，必须显式挂载到 SimpleRabbitListenerContainerFactory 上。否则即使写了 @Bean public RetryTemplate rabbitRetryTemplate()，也完全不生效。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 用
RetryInterceptorBuilder.stateless()构建拦截器，比直接 newRetryTemplate更安全（避免状态污染） -
recoverer必须指定，否则重试耗尽后默认会basicNack(requeue=true)，导致无限循环消费同一条失败消息 - 常见错误：漏写
.recoverer(new RejectAndDontRequeueRecoverer())，结果消息反复入队、反复失败、CPU 拉满 - 若要进死信队列，recoverer 应用
RepublishMessageRecoverer，并确保 DLX/DLQ 已正确定义
max-attempts 是「总调用次数」，不是「额外重试次数」
配置项 max-attempts: 3 表示：初次执行 + 最多再重试 2 次 = 总共最多执行 3 次。这点极易误解，导致实际重试次数比预期少一档。
- 如果业务方法第一次就抛异常，那还会再重试 2 次（第 2、3 次调用）
- 若设为
1，等于禁用重试（只执行一次，失败即走 recoverer） -
initial-interval和multiplier只在使用ExponentialBackOffPolicy时生效；yml 里写的initial-interval对应的是FixedBackOffPolicy，别混用策略 - 注意：yml 配置的
retry.enabled: true和 Java Config 方式互斥，二者同时存在时后者优先级更高
recoverer 选错会导致消息静默丢失或死循环
重试失败后交给哪个 MessageRecoverer 处理，决定了消息最终命运。它不是可有可无的兜底，而是关键分水岭。
-
RejectAndDontRequeueRecoverer：直接 reject 并丢弃（不 requeue），消息消失，适合幂等强、可容忍丢失的场景 -
RepublishMessageRecoverer：转发到指定 exchange/routingKey（如死信交换机），需提前声明 DLX/DLQ，否则消息被 RabbitMQ 丢弃且无日志 -
ImmediateRequeueMessageRecoverer：等价于basicNack(requeue=true)，慎用！没加次数限制就是死循环 - 自定义 recoverer 里不要 throw 异常，否则会触发容器级 error handler，可能跳过你预设的日志或补偿逻辑
