Java中RabbitMQ手动ACK需关闭autoAck、设预取数、业务成功后调basicAck、异常时区分basicNack/basicsReject，并配套幂等性、死信队列与可观测性。
Java 中 RabbitMQ 消费者通过手动 ACK 确认消息，核心是关闭自动签收、在业务真正执行成功后再显式调用 basicAck，并配合合理的异常处理与资源控制。这不是一个“调一下方法”就完事的操作，而是一套需闭环设计的可靠性保障机制。
关闭 autoAck 并配置预取数
消费者端必须将 autoAck 设为 false，否则 RabbitMQ 一发消息就直接删除，根本无从确认：
- 原生 Java 客户端：调用
channel.basicConsume(queueName, false, consumer) - Spring Boot 项目：在
application.yml中明确配置：
spring.rabbitmq.listener.simple.acknowledge-mode=manual - 限制并发处理量，防止消息“堆积未确认”：设置预取数（Prefetch Count），例如
channel.basicQos(1)，确保同一时间只处理一条消息，避免因某条卡住导致后续消息无法推进
在业务完全成功后才调用 basicAck
ACK 不是“收到即确认”，而是“已安全落地”的声明。提前调用等于主动丢消息：
- 必须把
channel.basicAck(deliveryTag, false)放在业务逻辑执行完毕、无异常抛出之后 - 推荐使用
try-catch-finally或try-with-resources结构包裹业务代码，仅在try块末尾调用 ACK - 切忌在数据库写入前、远程调用前、甚至日志打印前就 ACK——这些环节都可能失败
-
deliveryTag是当前 channel 级唯一标识，必须由接收该消息的同一 channel 实例调用，不可跨 channel 复用
异常时合理使用 basicNack 或 basicReject
不是所有异常都该重试，也不是所有失败都要丢弃。要根据错误性质做区分：
立即学习“Java免费学习笔记（深入）”；
- 可恢复异常（如临时 DB 连接超时、HTTP 熔断）：调用
channel.basicNack(deliveryTag, false, true)，第三个参数true表示重回队列，稍后重试 - 不可恢复异常（如 JSON 解析失败、非法订单号、违反唯一约束）：调用
channel.basicNack(deliveryTag, false, false)或channel.basicReject(deliveryTag, false)，拒绝并丢弃，避免无限循环 - catch 块中务必记录完整日志（含
deliveryTag和异常堆栈），便于排查 Unacked 消息卡点
配套措施缺一不可
单靠手动 ACK 不能防漏单，必须组合其他机制形成闭环：
-
幂等性：对关键操作（如下单、扣款）引入唯一业务 ID（如订单号）+ 数据库唯一索引 或 Redis
SETNX，防止重复消费引发重复执行 -
死信队列（DLX）：为队列配置
x-dead-letter-exchange，让多次重试失败的消息进入死信队列，供人工介入或异步补偿 -
可观测性：通过 RabbitMQ Web 控制台持续关注队列的
Unacked数量；若长期不降，说明 ACK 缺失、业务阻塞或 channel 泄漏 -
持久化基础：队列声明时设
durable=true，消息发送时设MessageProperties.PERSISTENT_TEXT_PLAIN，确保 Broker 重启后消息不丢失
