rabbitmq在autoack模式下消息发给消费者即删除，易丢失；应改用手动确认（autoack=false）、消息与队列持久化、合理qos及dlx兜底。
在 autoAck 模式下，RabbitMQ 一旦把消息发给消费者，就立刻从队列中删除，不等消费者处理完成。如果此时网络抖动导致消费者进程崩溃或断连，消息就彻底丢失——RabbitMQ 不知道它没被成功处理，也无法重发。这不是“死信”，而是“直接消失”。所以，autoAck 本质就不适合需要可靠投递的业务场景，解决方向不是“抢救已丢失的消息”，而是“避免让它丢失”。
停用 autoAck，改用手动确认（manual ack）
这是最根本、最有效的做法。开启手动确认后，RabbitMQ 会把消息标记为 unack 状态并留在队列中，直到消费者显式调用 channel.basicAck()；若消费者异常断开，未确认的消息会自动重新入队（前提是 channel 关闭前未 ack，且队列和消息都设置了持久化）。
- 创建消费者时设置
autoAck = false - 在业务逻辑执行成功后，再调用
channel.basicAck(deliveryTag, false) - 若处理失败，可选择
basicNack或basicReject并设置requeue = true让消息重回队列（注意循环消费风险）
配合持久化机制，守住消息底线
仅关掉 autoAck 还不够，还需确保消息和队列本身不会因 Broker 重启而丢失：
- 声明队列时设
durable = true - 发送消息时设
MessageProperties.PERSISTENT_TEXT_PLAIN（即 deliveryMode = 2） - 消费者 channel 也要在连接恢复后重新声明队列和绑定，避免因元数据丢失导致消息进错地方
用消费者预取（QoS）控制并发与风险范围
即使手动 ack，如果一次拉取太多消息又全部卡住或崩溃，恢复时可能批量重发、加重下游压力。通过 QoS 限制未确认消息数量，能缩小单次故障的影响面：
- 调用
channel.basicQos(1)表示最多只让一个消息处于 unack 状态 - 对吞吐敏感的场景，可适当提高（如 10），但需匹配消费者处理能力和超时机制
- 注意：QoS 是 channel 级别，每个 consumer channel 需单独设置
加一层兜底：死信交换器（DLX）捕获异常流转
有些失败不是临时抖动，而是业务逻辑持续报错（比如数据格式错误）。这时反复 requeue 会造成无效循环。建议结合 DLX 把多次失败的消息导向专门队列做人工干预或异步修复：
- 队列声明时设置
x-dead-letter-exchange和x-dead-letter-routing-key - 在
basicNack时设requeue = false，触发死信路由 - 可配合
x-max-retry-count（需插件）或应用层计数实现有限重试
不复杂但容易忽略：网络抖动只是表象，真正要防的是“消息发出即失守”的设计缺陷。autoAck 是性能换可靠性，生产环境几乎不该用。只要打开 manual ack + 持久化 + 合理 QoS，绝大多数抖动场景下消息都能稳住。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
