先把当时的情况摆出来。RabbitMQ 3.13 上一个消费者积压两万条 unacked，队列 Ready 数不再下降，消费者进程活着但 CPU 接近零，重启消费者后才恢复。
把日志和配置对完，能解释这个现象的基本就这几处。prefetch_count 设成 1000，消息全压在一个消费者手里。还有一种是处理线程池满了以后回调不再确认，形成死锁。
另外，某条消息处理永久阻塞且没有超时。少数情况下是channel 上开了手动确认但异常路径没 basic_nack。
上来先看队列的待确认消息数
rabbitmqctl list_queues name messages_ready messages_unacknowledged再往下把 prefetch 降到 20 并重启消费者
python worker.py --prefetch 20 --requeue-on-error给处理逻辑加超时与 nack 重投
python worker.py --timeout 30 --nack-on-timeout剩下的就是观察一段时间确认 Ready 持续下降
rabbitmqctl list_queues name messages_ready messages_unacknowledged怎么算真的好了，看的是同一批现象。unacked 数稳定在 prefetch 上限附近，Ready 数持续下降，消费者 CPU 回到正常水平，没有消息被反复重投。
unacked 堆积本质是确认跟不上投递，prefetch 过大时一条卡住就拖死整批，先限流再看单条处理超时。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。