必须配置限制、确认模式匹配与死信兜底三者协同：启用重试（enabled=true）、设最大尝试5次、指数退避间隔；auto确认模式触发自动重试，manual需手动nack；禁用默认重入队，转dlq或丢弃；代码层不可吞异常、慎用@transactional、避免@async抛异常。
消费端异常重试若不加约束，极易陷入无限循环——消息不断失败、不断重投、反复消费，既浪费资源又干扰业务。关键不是“要不要重试”，而是“怎么可控地重试”。核心在于配置限制 + 确认模式匹配 + 死信兜底三者协同。
必须开启并合理配置重试参数
仅靠默认行为无法规避死循环。需在 Spring Boot 配置中显式启用重试，并设定边界：
-
开启重试：
spring.rabbitmq.listener.simple.retry.enabled=true -
限制次数：
max-attempts=5（含首次消费，即最多尝试 5 次） -
控制间隔：用指数退避更稳妥，例如
initial-interval=1000、multiplier=2、max-interval=30000，避免瞬时密集刷屏
确认模式必须与重试机制对齐
重试是否生效，取决于消息确认方式：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- auto 模式才触发自动重试：Spring 捕获未处理异常后，自动 nack 并按配置重投；这是最常用且推荐的组合
-
manual 模式不走框架重试链：异常不会自动触发重试，需手动调用
basicNack(..., requeue=true)，否则消息直接卡住或丢失 - 绝不能设为 none：消息一送达即确认，失败也当成功，彻底失去重试机会
重试耗尽后必须有明确归宿
达到最大重试次数后，消息不能再原路返回队列，否则等于重启循环。必须指定最终流向：
-
禁用无脑重入队：
default-requeue-rejected=false（默认为 true，务必显式关闭） -
转发至死信队列（DLQ）：配置
RepublishMessageRecoverer，提前声明 DLX/DLQ，让失败消息沉淀下来人工干预或异步补偿 -
拒绝且丢弃：仅适用于幂等性强、可容忍丢失的场景，用
RejectAndDontRequeueRecoverer
代码层要放行异常，别截断重试链
再好的配置，也会被一段错误的 try-catch 毁掉：
-
不要在 @RabbitListener 方法里吞异常：写
try { ... } catch (Exception e) { log.error(...); }却不 re-throw，等于告诉框架“我处理完了”，消息被 ACK，重试失效 -
慎用 @Transactional 回滚范围：若只对
RuntimeException回滚，而业务抛出IOException，事务不回滚，异常也不触发重试 - 避免异步线程抛异常：@Async 中的异常无法传播回监听器线程，重试机制完全失效
