spring boot的@exceptionhandler无法捕获rabbitmq消费者异常，需配置simplerabbitlistenercontainerfactory的拒绝策略、手动nack并正确设置x-dead-letter-*队列参数，死信消费者须幂等处理且不可再配死信交换机。
全局异常捕获不等于消息异常处理
Spring Boot 的 @RestControllerAdvice 只能捕获 Web 层抛出的异常，对 RabbitMQ 消费者中发生的异常完全无效。消费者线程是独立于 HTTP 请求生命周期的，GlobalExceptionHandler 根本收不到消息处理失败时的 NullPointerException 或 JsonProcessingException。
真正起作用的是 Spring AMQP 提供的监听容器级错误处理机制，核心在 SimpleRabbitListenerContainerFactory 的配置上：
- 必须设置
setRejectRequeuePolicy(new AlwaysRejectRequeuePolicy())，否则默认会重试 3 次再丢弃，无法触发死信 - 需禁用自动 ack（即设为
ChannelAwareMessageListener模式），改用手动channel.basicNack(deliveryTag, false, false) - 若使用
@RabbitListener注解，应在方法内显式 throw 异常，并确保default-requeue-rejected=false配置生效
死信队列绑定必须用 x-dead-letter-* 参数，不能只靠 @Bean 声明
很多人以为只要声明了 deadLetterQueue() 和 DirectExchange("dlx.exchange") 并绑定，业务队列就能自动转发死信——这是错的。RabbitMQ 不识别 Spring 的 Bean 关系，只认队列声明时携带的 AMQP 扩展参数。
正确写法是给业务队列加参数，不是给死信队列加：
@Bean
public Queue orderQueue() {
return QueueBuilder.durable("order.queue")
.withArgument("x-dead-letter-exchange", "dlx.exchange")
.withArgument("x-dead-letter-routing-key", "order.dlq")
.withArgument("x-message-ttl", 30000)
.build();
}
注意：x-dead-letter-exchange 必须是非空字符串；若填空串，RabbitMQ 会使用默认交换机，但 routing key 若不匹配默认绑定，消息就丢了。
消费者手动 nack 是最可控的死信触发方式
依赖 TTL 过期或队列满来触发死信不可靠：TTL 是“消息级”超时，无法反映业务逻辑是否执行成功；队列长度限制又太粗粒度。最稳妥的做法是在消费者里捕获异常后主动 nack。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
示例消费逻辑：
@RabbitListener(queues = "order.queue")
public void processOrder(Message message, Channel channel, long deliveryTag) {
try {
String payload = new String(message.getBody());
// 业务处理
orderService.handle(payload);
channel.basicAck(deliveryTag, false);
} catch (Exception e) {
log.error("订单处理失败，进入死信队列", e);
try {
channel.basicNack(deliveryTag, false, false); // requeue=false 才进DLQ
} catch (IOException io) {
log.error("nack 失败", io);
}
}
}
关键点：basicNack(..., false, false) 第三个参数是 requeue，设为 false 才会走死信流程；设为 true 就是重新入队，可能造成无限循环。
死信消费者不能复用同一套异常处理逻辑
死信队列里的消息已经是“失败过一次”的消息，它的消费者不能再简单 throw 异常然后指望再次进 DLQ——RabbitMQ 不支持多级死信。一旦死信消费者也失败，且没做持久化或人工干预，消息就真丢了。
建议做法：
- 死信消费者必须带幂等校验（比如查 DB 确认该订单是否已补偿）
- 失败时记录到 DB 或发告警，而不是再 throw
- 不要给死信队列再配
x-dead-letter-exchange，避免误配置导致消息黑洞
最容易被忽略的是：死信消息的 header 里会自带 x-death 字段，记录它被拒绝的次数、原队列名、时间戳——这是排查重试链路的唯一依据，别在消费时把它过滤掉了。
