根本原因是任务处理逻辑异常或配置不当导致basicAck未发出，消息便长期卡在unacked状态；RabbitMQ不超时自动释放unacked消息，仅当消费者连接断开时才将其重置为ready。
根本原因不是 RabbitMQ 或 Celery 本身出错，而是任务处理逻辑或配置导致消息无法正常确认——只要 basicAck 没发出去，消息就永远卡在 unacked 状态。
为什么 Celery 的 unacked 消息不自动清零？
Celery 默认启用手动 ACK（acknowledges=True），这是正确做法，但代价是：一旦任务函数抛异常、进程被杀、或未执行完就退出，RabbitMQ 就收不到 basicAck。此时消息不会消失，也不会重入队，而是持续显示为 unacked，直到连接断开才触发重投。
- 常见诱因：任务里调用
sys.exit()、被kill -9强杀、Docker 容器 OOM 被 kill、或 Celery worker 进程意外崩溃 - 注意：
unacked=0并不表示“一切正常”，它只说明当前连接上没有待确认消息——可能刚断连重连，也可能所有消费者都挂了 - 别信“过一阵自己好了”：unacked 不会超时自动释放，RabbitMQ 不做超时 ACK
检查 consumer 是否真的在消费
运行 rabbitmqctl list_consumers，重点看三列：queue、consumer_tag、prefetch_count。如果某个 queue 显示有 consumer，但 unacked 持续上涨，说明 consumer 线程活着，但没推进 ACK。
- 用
rabbitmqctl list_queues name messages_unacknowledged consumers确认哪个 queue 堆积最严重 - 进管理界面（
http://localhost:15672）点开该 queue，看 “Consumers” 下的 “Unacked message count” 是否和总数一致——若一致，说明所有消息都被同一个 consumer 拉走却卡住了 - 检查 worker 日志是否频繁出现
Consumer cancelled by application或ConnectionClosed，这代表 channel 被提前关闭，ACK 失效
修复 Python/Celery 的 ACK 失败链路
Celery 的 ACK 是在任务函数返回后由 worker 主动发送的，中间任何环节中断都会导致失败。最常被忽略的是异常捕获不全和资源清理冲突。
立即学习“Python免费学习笔记（深入）”；
- 确保
task_acks_late=False（默认值），即 ACK 在任务开始前发出 → 错！这会让失败任务直接丢失；应保持task_acks_late=True，让 ACK 延迟到任务成功返回后 - 禁用
worker_prefetch_multiplier=1（默认值），避免单个 worker 预取过多消息却卡住；生产环境建议设为1或2 - 在任务函数内不要用
try/except + return吞掉所有异常，尤其不能忽略KeyboardInterrupt和SystemExit—— 它们会导致 worker 退出前来不及发 ACK - 如果你手动调用了
channel.basic_nack()或reject()，必须传requeue=False，否则消息会重新进 ready 队列，但 delivery_tag 已失效，下次投递会带redeliver=True标记
验证修复是否生效的最小闭环
别等线上堆积，本地就能快速验证：
celery -A tasks worker --loglevel=info --concurrency=1
然后发一个必失败的任务：
@shared_task(bind=True, autoretry_for=(Exception,), retry_kwargs={'max_retries': 0})
def failing_task(self):
raise Exception("simulated fail")
观察两点：
- RabbitMQ 管理界面中该 queue 的
unacked是否始终为 0（失败任务不占 unacked，因为没进入处理阶段） - 成功任务执行后，
unacked是否瞬间归零，且日志出现Task tasks.failing_task[...]: acknowledged - 手动 kill worker 进程后，原 unacked 消息是否在 30 秒内变为 ready（RabbitMQ 默认检测断连超时为 30s）
真正难处理的不是堆积本身，而是 unacked 消息背后那个“看似在跑、实则不动”的消费者——它不报错、不退出、不释放资源，只安静地把消息锁死。盯住 consumer 状态比盯住数字更重要。
