rabbitmq消费端异常时是否自动nack并重新入队取决于确认模式和配置；默认simplemessagelistenercontainer抛出未捕获异常会basicnack，但需显式设requeue=true才重新入队，推荐配置defaultrequeuerejected=true并禁用auto模式。
当 RabbitMQ 消费端处理消息失败抛出异常时，是否自动 Nack 并重新入队，取决于你使用的确认模式（Acknowledge Mode）和异常处理配置。默认情况下，Spring AMQP 的 SimpleMessageListenerContainer 在抛出未捕获异常时会触发 basicNack，但是否重新入队（即 requeue = true）需要显式配置，否则消息可能被丢弃或进入死信队列。
启用手动 Ack 并控制 requeue 行为
最可靠的方式是关闭自动 Ack，改用手动确认，并在 catch 异常后主动调用 channel.basicNack(deliveryTag, false, true)：
-
设置
acknowledgeMode=MANUAL：在容器工厂中配置，禁用自动确认 -
在 @RabbitListener 方法中注入
Channel和Message：用于手动发 nack -
捕获异常后调用
channel.basicNack(..., requeue=true)：第三个参数requeue设为true才会重回队列头部
使用 Spring 的 @RabbitListener 默认行为（推荐简化方案）
Spring AMQP 提供了更简洁的配置方式，无需手动操作 Channel：
-
配置
defaultRequeueRejected = true（容器工厂级别）：这是关键开关，表示所有被拒绝（包括未捕获异常）的消息都默认 requeue -
确保
acknowledgeMode = NONE或MANUAL不启用 AUTO：AUTO 模式下异常会导致消息直接丢弃（不 requeue） -
避免在监听方法中吞掉异常：如果 try-catch 后没抛出，框架认为消费成功；必须让异常透出或显式调用
Reject
注意 requeue 的潜在风险
无限重试会导致消息反复入队、消费者持续失败，甚至阻塞队列：
-
建议搭配死信队列（DLX）使用：设置
x-max-retries或利用 TTL + DLQ 转移反复失败的消息 -
慎用
requeue=true处理逻辑错误：比如反序列化失败、空指针等应修复代码，而非重试 - 网络/临时故障适合 requeue，业务校验失败建议直接 reject（
requeue=false）
配置示例（Java Config）
以下为典型安全配置：
factory.setAcknowledgeMode(AcknowledgeMode.MANUAL); factory.setDefaultRequeueRejected(true); // ← 关键！ // 或者更细粒度控制： factory.setAdviceChain(new ConditionalRejectingErrorHandler());
同时，在监听器中可选择性地抛出 AmqpRejectAndDontRequeueException 来强制不重入队，覆盖默认行为。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
