必须关掉 auto_ack 改用手动确认，否则超时会导致 RabbitMQ 误判消费者失联而重发消息；因其采用“至少一次投递”策略，auto_ack=True 时消息送达即删除，auto_ack=False 时超时未 ack 则 requeue。
必须关掉 auto_ack，改用手动确认（basic_ack），否则超时即重发
为什么超时会导致消息被重复分配？
RabbitMQ 默认采用 “至少一次投递” 策略。当消费者启用 auto_ack=True 时，消息一送达就立刻从队列删除；但若你用的是手动确认模式（auto_ack=False），RabbitMQ 会等待消费者显式调用 basic_ack。如果消费者处理时间超过 RabbitMQ 的 heartbeat 或 consumer timeout（比如网络卡顿、DB 延迟、第三方接口 hang 住），Broker 会认为该消费者已失联，自动把消息 requeue 给其他在线消费者 —— 这就是重复分配的根源。
如何设置合理的 consumer timeout 和 heartbeat？
关键不是“延长超时”，而是让 RabbitMQ 准确感知你的存活状态：
-
heartbeat=30是推荐起点：客户端每 30 秒发一次心跳包，Broker 超过 90 秒没收到就断连（默认是 3×heartbeat） - 在
pika.ConnectionParameters中显式传入，不要依赖服务端默认值（可能为 0，即禁用心跳） - 避免设
heartbeat=0：这等于关闭保活机制，网络抖动后极易触发误判重发 - consumer 端处理逻辑里，别用
time.sleep(60)这类阻塞操作；如需长耗时任务，应拆成异步+状态轮询，或改用basic_nack(requeue=False)主动拒绝并落库重试
超时发生前，怎么主动续命或安全放弃？
不能靠等超时，得主动管理生命周期：
立即学习“Python免费学习笔记（深入）”；
- 对可能超时的操作（如 HTTP 请求、数据库写入），加
timeout参数并捕获requests.Timeout或psycopg2.OperationalError等异常 - 一旦检测到处理接近超时（例如已过去 45 秒，而 heartbeat=30），立即调用
channel.basic_nack(delivery_tag=method.delivery_tag, requeue=False)，把消息移出队列，进死信交换机（DLX）后续人工干预 - 切勿在未完成业务逻辑时调用
basic_ack，否则数据不一致；也别在异常分支里漏掉basic_nack，否则消息卡住不动 - 生产环境建议搭配
prefetch_count=1：限制单个消费者最多只拿 1 条未确认消息，防止积压阻塞其他实例
本地处理超时 ≠ 消息要重试，得区分场景做决策
超时本身不是错误，而是信号 —— 它告诉你这条消息当前不适合继续处理：
- 如果是临时性依赖不可用（如下游 API 503），适合
basic_nack(requeue=True)并加expirationTTL 控制重试次数 - 如果是业务逻辑卡死或数据异常（如解析失败、ID 格式错误），应该
basic_nack(requeue=False)+ 发送告警，避免无限循环 - 所有
nack操作都必须在同一个channel上执行，且 delivery_tag 不能复用；跨线程传递 delivery_tag 很容易出错，建议用闭包或上下文绑定
真正难的不是写 basic_ack，而是判断“现在该 ack 还是 nack”，以及 nack 后消息去哪——这些逻辑一旦写错，轻则重复消费，重则消息黑洞。别省那几行 if 判断。
