at least once 依赖 consumer 显式调用 basicack() 与 broker 重发机制协同实现，非一键开关；autoack=true 则退化为 at most once，消息一接收即删除，不保障送达。
At least once 的实现依赖于 consumer ACK + broker 重发
它不是靠“开关”一键开启的，而是由 RabbitMQ 默认行为 + 消费端配合共同达成。关键点在于：消费者处理完消息后，必须显式调用 channel.basicAck()；如果没调用、连接断开、或超时未响应，broker 就会把这条消息重新入队（或投递给其他 consumer）。
常见错误现象包括：
- 忘记在 try-catch 后写
basicAck()，导致消息无限重回队列 - 在
basicAck()前抛出异常，而异常被吞掉（比如空 catch），ACK 实际未发出 - 使用了 autoAck = true，相当于直接关闭了这一保障机制
性能影响明显：每次 ACK 都是网络往返，高吞吐场景下建议批量 ACK（multiple=true），但要注意这会丢失“部分失败”的精确控制能力。
At most once 本质是关闭可靠性机制
它不靠额外配置，而是通过主动放弃确认和持久化来实现。典型做法就是设置 autoAck = true，让 consumer 一收到消息就自动标记为已处理，broker 立即删除该消息——哪怕 consumer 进程随后崩溃，消息也找不回来了。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
使用场景非常有限：
- 日志上报类任务，如每分钟推送一次服务器 CPU 使用率，丢一条无所谓
- 监控埋点数据，强调低延迟而非完整性
- 测试环境快速验证通路，不关心是否送达
注意：autoAck = true 下，即使你把 queue 设为 durable、message 设为 persistent，也毫无意义——因为消息还没落地就被认为“已完成”了。
为什么不能只靠配置就切换语义？
At least once 和 At most once 不是 RabbitMQ 的两个独立模式，而是同一套机制（AMQP 协议中的 delivery tag + ack 流程）在不同使用方式下的结果。真正起决定作用的是 consumer 侧是否发送 ACK、何时发送、是否重试、是否幂等。
容易被忽略的一点是：即使你启用了 basicAck()，若 consumer 处理逻辑本身不可重入（比如扣款没加幂等判断），那 At least once 反而会引发重复扣款——保障了“不丢”，却破坏了“不错”。所以语义落地，从来不只是 broker 的事。
