auto_ack=true时消息立即确认并删除，不等待业务处理完成；auto_ack=false需手动调用basic_ack，否则消息滞留unacked状态，适用于高可靠性场景。
auto_ack=True 时消息一发就丢，不等业务处理完
开启 auto_ack=True 意味着 RabbitMQ 在把消息推给消费者后，**立刻标记为已确认并从队列中移除**，不管你的回调函数是否执行完毕、有没有抛异常、甚至还没开始处理。
常见错误现象：callback 函数里有耗时操作或网络请求，但进程意外崩溃（比如 Ctrl+C、OOM、未捕获异常），此时消息已经消失，无法重试——典型的“消息丢失”场景。
适用场景仅限于：日志采集、监控埋点、通知类低可靠性要求任务。别用在订单创建、支付回调、库存扣减这类必须“至少处理一次”的逻辑里。
auto_ack=False 要求手动调用 basic\_ack，否则消息卡在 Unacked 状态
关闭 auto_ack 后，RabbitMQ 会把消息状态从 Ready 变成 Unacked，并等待你显式调用 channel.basic_ack(delivery_tag=method.delivery_tag)。只有这时它才真正删除消息。
容易踩的坑：
- 忘记在
callback末尾加basic_ack，导致消息堆积在 Unacked，队列看起来“卡住”了 - 在
try/except里只处理了成功路径，异常分支没做basic_nack(requeue=True)，结果消息直接被丢弃 - 多个线程共用一个
channel，delivery_tag跨通道无效，调用basic_ack报错ChannelClosedByBroker
示例关键片段：
def callback(ch, method, properties, body):
try:
# 处理业务逻辑
process_order(body)
ch.basic_ack(delivery_tag=method.delivery_tag) # ✅ 必须写
except Exception as e:
# ❌ 不要 silence 异常，至少 basic_nack(requeue=True)
ch.basic_nack(delivery_tag=method.delivery_tag, requeue=True)
Web 控制台里能看到 Ready 和 Unacked 的数量差异
RabbitMQ 管理界面的 Queue 页面，实时显示两个关键数字：
-
Ready：等待分发的新消息数 -
Unacked：已发出但尚未收到basic_ack的消息数
如果 Unacked > 0 且长时间不降，基本可以断定是消费者没调 basic_ack，或者消费者进程挂了但连接没断（TCP 连接还活着，RabbitMQ 不知道它已失效）。
注意：auto_ack=False 下，消费者断连后，RabbitMQ 会在检测到连接关闭后自动把所有 Unacked 消息重新置为 Ready，所以别指望靠这个机制兜底——得靠超时重试 + 幂等设计。
basic\_consume 的 auto\_ack 和 basic\_get 的 auto\_ack 行为一致但语义不同
basic_consume 是“订阅式消费”，auto_ack 控制的是后续每条推送消息的确认时机；而 basic_get 是“拉取式”，每次只取一条，它的 auto_ack 参数决定这一条是否立即确认。
两者底层确认逻辑完全一样，但使用姿势差别大：
- 用
basic_consume+auto_ack=False是标准做法，适合长连接、持续消费 - 用
basic_get通常只用于调试或低频轮询，性能差，不推荐生产环境高频调用
别混淆：无论哪种方式，只要 auto_ack=False，你就得自己管 basic_ack，没有例外。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
