手动ack不能单独保证消息不丢失，需配合持久化、预取限制、异常处理闭环四点落地；必须禁用自动ack，设置prefetch为1起，业务成功后才basicack，可恢复异常调用basicnack重入队，队列与消息均需持久化。

手动 ACK 本身不能单独“保证消息不丢失”，但它是最关键的一环——它把消息是否删除的控制权交还给业务代码，为重试、兜底和异常恢复留出空间。真正实现不丢，需要 ACK 配合持久化、预取限制、异常处理闭环这四点一起落地。

开启手动确认并禁用自动 ACK

这是前提，否则 RabbitMQ 会在发出去的瞬间就删掉消息。

• Spring Boot 中在 application.yml 里明确配置：
  

  spring:<br>  rabbitmq:<br>    listener:<br>      simple:<br>        acknowledge-mode: manual

• 原生 Java 客户端创建消费者时，autoAck 必须设为 false：
  channel.basicConsume(queueName, false, consumer);

设置合理的 prefetch count（预取数量）

不设或设得太大，会导致大量消息被拉到消费者内存但未处理完，一旦进程崩溃，这些消息就处于“无人认领”状态，既没 ACK 也没 NACK，RabbitMQ 会一直等待，最终可能堆积甚至阻塞队列。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 推荐从 1 开始，即一次只取一条：
  channel.basicQos(1);
• 若吞吐压力大，可逐步调高（如 5 或 10），但必须同步加强业务超时和异常兜底逻辑。

在业务完全成功后才发送 basicAck

ACK 是“我已安全落地”的声明，提前发等于主动丢消息。

• 必须包裹在 try-catch-finally 或 try-with-resources 结构中，确保只有业务逻辑执行完毕、无异常时才调用：
  channel.basicAck(deliveryTag, false);
• 切忌在 try 块开头、数据库操作前、远程调用前就 ACK。
• 如果业务抛出的是可恢复异常（比如临时数据库连接失败），应调用：
  channel.basicNack(deliveryTag, false, true);
  其中第三个参数 true 表示重新入队，让消息稍后重试。

做好持久化配套，避免 Broker 重启丢消息

手动 ACK 只管消费端流程，但如果消息本身没落盘，Broker 一重启，队列空了，再好的 ACK 也无从谈起。

• 声明队列时加 durable = true：
  channel.queueDeclare(queueName, true, false, false, null);
• 发送消息时设置 持久化属性：
  MessageProperties.PERSISTENT_TEXT_PLAIN
• 确保交换机（Exchange）也是 durable 的（默认创建的通常都是）。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南