RabbitMQ消费失败重试依赖Spring AMQP自动机制，核心是未捕获异常在auto确认模式下触发配置化重试；manual模式需手动nack；必须启用retry.enabled=true且避免try-catch吞异常；重试耗尽后由MessageRecoverer决定消息去向。
Java中RabbitMQ消费失败时利用异常链重试，核心不是靠“捕获异常再手动抛出”来触发重试，而是依赖Spring AMQP的自动重试机制与异常传播逻辑协同工作。关键在于：让未处理的异常自然向上抛出，且不被吞掉，才能进入重试流程。
确保异常能触发重试的确认模式
只有在acknowledge-mode: auto（自动确认）下，Spring才会在捕获到未处理异常后自动拒绝消息并按配置重试。若设为manual，需自行调用basicNack(..., requeue=true)，此时异常链本身不参与重试决策。
- 配置必须显式启用：
spring.rabbitmq.listener.simple.retry.enabled=true - 确认模式必须是
auto，不能是manual或none - @RabbitListener方法内不要try-catch住所有异常——吞掉异常等于阻断重试链
异常链中哪些异常会被重试识别
Spring默认对所有Throwable子类都视为可重试异常，但实际生效取决于是否被框架捕获。常见有效场景：
- 业务代码抛出
RuntimeException（如NullPointerException、IllegalArgumentException） - 调用外部服务时抛出
IOException、TimeoutException等检查异常（需未被捕获） - 自定义异常继承
RuntimeException，且未在监听器内处理
注意：Error类（如OutOfMemoryError）通常不建议重试，Spring默认也会跳过；若需特殊处理，需自定义RetryPolicy。
立即学习“Java免费学习笔记（深入）”；
避免异常链被意外截断
以下写法会破坏重试机制，务必规避：
- 在@RabbitListener方法里用
try {...} catch (Exception e) { log.error(...); }却不重新throw - 使用
@Transactional时发生回滚异常，但事务配置了rollbackFor范围过窄，导致部分异常未触发回滚和重试联动 - 异步调用（如
@Async）中抛出异常，因线程切换导致异常无法传播回监听器线程
结合recoverer控制最终流向
当重试耗尽后，异常链已结束，此时由MessageRecoverer决定消息去向：
-
RejectAndDontRequeueRecoverer：丢弃消息（适合幂等强、可容忍丢失） -
RepublishMessageRecoverer：转发至死信交换机（需提前声明DLX/DLQ） - 自定义recoverer可提取原始异常信息，例如记录
e.getCause().getClass().getSimpleName()用于分类告警
recoverer必须显式配置，否则默认行为是basicNack(requeue=true)，造成无限循环。
