basicReject用于单条消息拒绝，basicNack支持批量拒绝（multiple=true），二者均需设requeue=false并配合死信队列（DLX）才能确保异常消息被安全捕获而非无限重试或丢失。
RabbitMQ 中，basicReject 和 basicNack 是消费者端主动拒绝消息的核心方法，用于处理恶意消息、反序列化失败、业务校验不通过等异常场景。关键不是“拒掉就完事”，而是要结合 重试机制、死信队列（DLX） 和 拒绝策略（requeue） 来避免消息丢失或无限循环消费。
何时用 basicReject，何时用 basicNack？
basicReject 仅支持单条消息拒绝；basicNack 支持批量拒绝（通过 multiple=true），且语义更明确（Negative Acknowledgement）。在 Java 客户端（如官方 amqp-client）中：
- 若只拒绝当前一条消息 → 两个方法效果一致，推荐用
basicReject，语义清晰 - 若需一次性拒绝多条未 ack 的消息（例如批量消费时某条出错，想把前面几条也退回）→ 必须用
basicNack并设multiple=true -
basicNack是basicReject的超集，新项目建议统一使用basicNack，便于后续扩展
requeue = false 才是“真正拒绝”，否则只是重新入队
很多人误以为调用 reject/nack 就等于丢弃消息，其实关键在 requeue 参数：
-
requeue = true：消息会重回队列头部，可能被**同一消费者或其它消费者立即再次投递** → 容易造成无限重试、CPU 打满、日志刷屏 -
requeue = false：消息被 RabbitMQ 移除（不进队列也不进 DLX），除非你配置了死信交换器（DLX），否则它就“消失”了（进入黑洞） - ✅ 正确做法：解析失败/非法消息（如 JSON 格式错误、含恶意 payload）应设
requeue = false，再配合 DLX 转发到死信队列做审计或人工干预
必须搭配死信队列（DLX）才能安全落地拒绝逻辑
单纯 basicNack(tag, false) 不会自动进死信队列 —— RabbitMQ 要求队列**预先声明 DLX 和 DLK（死信 Routing Key）** 才能触发死信路由：
立即学习“Java免费学习笔记（深入）”；
- 声明原队列时添加参数：
arguments.put("x-dead-letter-exchange", "dlx.exchange") - 可选加：
arguments.put("x-dead-letter-routing-key", "dlq.routing.key") - 绑定一个死信交换器（如 direct 类型）到死信队列（DLQ），确保
requeue=false拒绝的消息能被捕获 - 示例场景：收到 base64 编码的 payload，解码后发现是 script 标签或 SQL 片段 → 直接
channel.basicNack(envelope.getDeliveryTag(), false)，消息进 DLQ，后台告警+人工核查
避免“假拒绝”：别在 catch 块里裸调 reject/nack
常见错误写法：
try {
process(msg);
} catch (Exception e) {
channel.basicNack(tag, false); // ❌ 可能抛出 IOException，导致消息既没处理也没拒绝
}正确姿势：
- 在
finally或 try-with-resources 后确保拒绝逻辑执行完毕 - 捕获
IOException并记录 error 日志，必要时触发熔断或告警 - 对反序列化类（如 Jackson）启用严格模式（
DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES），让解析失败直接 throw，便于统一拦截 - 考虑封装工具方法：
safeReject(channel, tag, requeue, reason)，内部处理异常并打点监控
不复杂但容易忽略：拒绝消息本身也是 RPC 调用，网络波动或连接中断时可能失败。生产环境务必检查 channel 状态、设置超时、加上重试（最多 1–2 次）和降级日志。
