手动应答（manual）是生产环境默认安全选择；自动应答（auto）仅适用于日志等可丢失场景，因消息一送达即被rabbitmq删除，崩溃或异常时无法重试，易致消息静默丢失。
手动应答（MANUAL）是生产环境的默认安全选择；自动应答（AUTO）只适合日志、埋点等可丢失场景，用错会直接导致消息静默丢弃。
为什么自动ACK会导致消息“消失”而不是重试
自动ACK的本质是：只要消息被推送到消费者线程（哪怕还没执行业务逻辑），RabbitMQ 就立即认为已确认，并从队列中删除。此时如果消费者进程崩溃、OOM 或在 onMessage 开头就抛出未捕获异常，RabbitMQ 完全不知情。
-
autoAck=true时，channel.basicConsume(queue, true, ...)的第二个参数为true，ACK 在 delivery 后瞬间触发 - Spring AMQP 中若未显式配置
acknowledge-mode，底层仍走AUTO模式（不是NONE），但异常时是否重投取决于default-requeue-rejected配置，默认为true—— 这容易让人误以为“它会重试”，其实只是“异常时临时回队”，而进程重启后该消息早已不在队列里 - 典型错误现象：
RuntimeException抛出后控制台看不到消息重入日志，监控发现队列长度归零，但业务数据缺失
手动ACK必须配合 prefetch=1 和 channel.basicAck() 调用
手动模式下，不调用 basicAck()，消息就一直卡在 unack 状态，既不被删除，也不会发给其他消费者（除非 channel 断开）。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 必须在
application.yml中设置spring.rabbitmq.listener.simple.prefetch: 1，否则 RabbitMQ 可能预取多条，而你只处理了第一条就崩了，其余几条会滞留在当前 channel，造成“假死”积压 - 在
ChannelAwareMessageListener.onMessage(Message message, Channel channel)中，需显式调用channel.basicAck(message.getMessageProperties().getDeliveryTag(), false) - 不要漏掉
catch块里的basicNack()或basicReject()：比如channel.basicNack(deliveryTag, false, true)表示拒绝当前消息并重新入队（requeue=true） - 注意
deliveryTag是 per-channel 递增的 long 值，不能跨 channel 复用，也不能存起来异步 ack
Spring Boot 中开启手动ACK的两个关键位置
只改配置文件或只改代码都不够，二者必须一致，否则 Spring AMQP 会 fallback 到 AUTO。
- 配置文件必须写全：
spring.rabbitmq.listener.simple.acknowledge-mode: manual，且不能拼错acknowledge-mode（常见错写成ack-mode或acknowledgement-mode） - 消费者类必须实现
ChannelAwareMessageListener接口，或使用@RabbitListener+@RabbitHandler组合，并确保方法签名含Channel参数（如public void listen(String msg, Channel channel)），否则 Spring 不会注入Channel，basicAck()无处调用 - 如果用了
SimpleRabbitListenerContainerFactory自定义 Bean，必须显式调用factory.setAcknowledgeMode(AcknowledgeMode.MANUAL)，否则配置文件中的设置会被忽略
最容易被忽略的是：手动 ACK 后必须确保 channel 未关闭，且不能在异步线程里调用 basicAck() —— RabbitMQ 的 channel 不是线程安全的，跨线程 ack 会抛 IllegalStateException 或静默失败。
