java中rabbitmq手动应答需设autoack=false，业务成功后调用basicack(deliverytag,false)，失败时用basicnack(requeue=true/false)；务必在同一线程try-catch内完成处理与确认，避免unacked堆积。
Java 中 RabbitMQ 通过消费端手动应答（manual acknowledgment）机制，即调用 basicAck，来确保消息只有在业务逻辑真正处理成功后才被 RabbitMQ 从队列中移除。这能有效避免消息丢失或重复消费——前提是消费者不自动确认、不异常崩溃、且在确认前不丢弃消息。
开启手动应答模式
创建消费者时必须关闭自动确认（autoAck = false），否则 RabbitMQ 会在消息投递后立即删除它，不管后续是否处理成功。
- 使用
channel.basicConsume(..., false, ...)，第3个参数设为false - 若用 Spring AMQP，需配置
SimpleMessageListenerContainer或DirectMessageListenerContainer的acknowledgeMode为MANUAL - 注意：一旦关闭 autoAck，就必须显式调用
basicAck或basicNack，否则消息会一直留在 unacked 状态，占用队列资源
正确调用 basicAck 的时机
basicAck 应在业务逻辑**完全执行完毕且无异常**后调用，且必须传入对应消息的 deliveryTag。
- deliveryTag 是 RabbitMQ 分配给每条投递消息的唯一整数标识，由
Delivery对象提供，不可自行构造 - 典型写法：
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false) - 第二个参数 multiple = false 表示只确认当前这条；设为 true 则确认所有小于等于该 deliveryTag 的未确认消息（慎用，易误确认）
- 务必放在 try 块末尾，或确保在 finally 之外、业务成功路径的最后一步执行
配合 basicNack 或 basicReject 处理失败
当业务处理失败（如数据库异常、校验不通过），不应沉默忽略，而应主动拒绝消息，以便重试或进死信队列。
-
basicNack(deliveryTag, false, true)：拒绝当前消息，并允许重新入队（requeue = true） -
basicReject(deliveryTag, false)：等价于 basicNack(..., false)，但不支持批量拒绝 - 若不希望重试（如数据非法），则设
requeue = false，再配合死信交换机（DLX）做后续处理 - 切忌在 catch 块里什么都不做——消息将一直处于 unacked 状态，阻塞队列并可能触发消费者连接超时
保障手动应答的可靠性
手动应答本身不保证原子性，需结合代码结构与异常处理规避“处理成功但没发 ack”或“发了 ack 但实际没处理完”的风险。
- 把业务逻辑和
basicAck放在同一 try-catch 内，成功则 ack，异常则 nack - 避免在异步线程中处理消息后回调 ack —— deliveryTag 只在当前消费线程有效，跨线程 ack 会报错或无效
- 开启 channel 的 confirm 模式对生产者有用，但不影响 consumer ack；consumer 端无需额外 confirm 配置
- 监控 unacked 消息数（
rabbitmqctl list_queues name messages_unacknowledged），持续增长说明 ack 逻辑有遗漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
