Spring AMQP 不提供 MessageBatchRecoverer，异常处理始终以单条消息为粒度；批量消费中需手动实现整批恢复逻辑，如统一抛异常、自定义 recoverer 或手动 ACK。
在 RabbitMQ 的 Spring AMQP 中，MessageBatchRecoverer 并不是一个内置或官方支持的恢复机制。Spring AMQP 目前（截至 3.0.x）**不提供原生的“批处理异常恢复器”**，也没有名为 MessageBatchRecoverer 的标准接口或实现类。你可能混淆了以下两个概念：
1. BatchMessageListener 或 SimpleBatchMessageListener：用于批量消费消息（如一次拉取多条），但异常处理仍以单条消息粒度进行；
2. MessageRecoverer（如 DefaultMessageRecoverer、RepublishMessageRecoverer）：作用于单条失败消息，不是批量。
为什么 throw 异常不会触发“批恢复”？
RabbitMQ Listener（尤其是基于 @RabbitListener 的方法）在批量模式下（如设置 batch = true），底层会把一批消息封装为 List<Message> 传入监听方法。但 Spring AMQP 的错误处理机制仍是逐条校验和处理：
立即学习“Java免费学习笔记（深入）”；
- 即使你 throw 一个异常，容器默认会将整个批次视为“失败”，但恢复逻辑（如重试、死信、重发）依然针对每条消息单独执行；
- 没有“只恢复其中某几条”或“统一提交/回滚整批”的事务语义（RabbitMQ 本身也不支持跨消息事务）；
-
MessageRecoverer的recover(Message, Throwable)方法入参始终是单条Message，而非List<Message>。
如何实现类似“批感知”的恢复行为？
若你希望在批量消费中统一决策是否恢复/丢弃/重发整批，需手动控制异常时机与恢复逻辑：
-
不在循环内 throw：避免单条失败立即中断批次。先收集失败项，方法末尾统一 throw 自定义异常（如
BatchProcessingException）； -
自定义
MessageRecoverer：虽然接口是单条，但你可以通过消息属性（如message.getMessageProperties().getHeader("batch-id")）识别同批消息，在 recover 时查表/缓存判断是否整批失败，再决定动作； -
用
RetryTemplate+ 批量重试策略：在监听方法内对整个List<Message>做带状态的重试，失败后由外部逻辑触发整批补偿（如写入 DB 标记 + 定时任务）； -
放弃自动恢复，改用手动 ACK + 显式处理：禁用
acknowledgeMode=MANUAL，在 catch 异常后根据业务规则调用channel.basicNack(...)或basicReject(...)，并自行投递到重试队列或 DLQ。
常见误区提醒
• 不要依赖 throw new RuntimeException() 触发“批恢复”——它只会让当前批次停止处理，后续消息照常拉取；
• DefaultBatchErrorHandler 只负责记录日志或跳过失败项，不触发 recoverer；
• 若使用 SimpleBatchMessageListener，其 setBatchErrorHandler 设置的是 BatchErrorHandler，与 MessageRecoverer 无关；
• Spring AMQP 的 RepublishMessageRecoverer 仅适用于单条消息重发布，无法保证批量原子性。
如果你实际需要的是“某批中部分成功、部分失败时的精细化恢复”，建议绕过自动恢复机制，改用幂等 + 补偿事务 + 消息状态跟踪的方式实现。
