直接用pika.BlockingConnection易断连，因其在网络抖动或broker重启时静默失败、不抛异常也不重连，导致程序卡住却 unaware 连接已断；需显式配置heartbeat、retry_delay等参数或改用更健壮的连接方式。
为什么直接用 pika 连 RabbitMQ 容易断连？
默认的 pika.BlockingConnection 在网络抖动或 broker 重启时会静默失败，不抛异常也不重连。你看到任务“卡住”，其实连接早断了，但程序还在等消息——根本没意识到连不上。
实操建议：
- 改用
pika.SelectConnection或更稳妥的aiormq（异步） /pika.adapters.blocking_connection.BlockingConnection配合手动心跳和重试逻辑 - 必须显式设置
connection_parameters = pika.ConnectionParameters(heartbeat=30, retry_delay=2, connection_attempts=5) - 不要依赖 try-except 包裹
channel.basic_publish就算完事——发布失败时，pika可能只抛ConnectionClosedByBroker，但前提是你要开了confirm_delivery=True
basic_publish 发不出消息？检查这三处
常见现象是生产者无报错，但消费者收不到任何消息，队列里空空如也。
原因往往不在代码逻辑，而在声明与绑定细节：
- 交换机（exchange）没声明，或声明类型（
direct/topic）和路由键（routing_key）不匹配 → 消息被丢弃，RabbitMQ 默认静默处理 - 队列（queue）没设
durable=True，broker 重启后队列消失，但生产者仍往不存在的队列发消息 → 消息直接 404 - 没调用
channel.queue_bind，即使队列和交换机都存在，若没绑定，消息进不来
示例关键片段：
channel.exchange_declare(exchange='task_exchange', exchange_type='direct', durable=True) channel.queue_declare(queue='task_queue', durable=True) channel.queue_bind(exchange='task_exchange', queue='task_queue', routing_key='task')
消费者怎么避免“消费一次就退出”？
用 channel.basic_consume 后忘了调 connection.start_consuming()，或者用了 channel.basic_get 轮询——后者本质是同步拉取，不是长连接监听，极易漏消息、压不住并发。
正确姿势是保持一个长期运行的 consumer loop：
- 用
auto_ack=False，处理完再显式channel.basic_ack，否则进程崩溃时消息就丢了 - 加
channel.basic_qos(prefetch_count=1)，防止一个消费者扛满所有积压，其他实例闲着 - 处理函数里别写阻塞操作（如 requests.get 不带 timeout），超时会导致 RabbitMQ 认为消费者挂了，把消息重新入队甚至重复投递
Python worker 进程意外退出时，消息去哪了？
这是最常被忽略的点：没开 manual ack + 没设 requeue=False，worker 崩溃后，RabbitMQ 会把未 ack 的消息放回队列头部——下个 worker 立刻又拿到，形成无限重试循环，还可能触发死信。
对策很直接：
- 所有 consumer 必须用
auto_ack=False - 在
try/except中包裹业务逻辑，成功才basic_ack；失败时根据错误类型决定是否basic_nack(requeue=False)（进死信）或requeue=True（有限重试） - 提前声明死信交换机（DLX）和死信路由键，不然
requeue=False的消息就彻底消失了
真正麻烦的从来不是“怎么发消息”，而是“消息发出去之后，谁负责它到底有没有被可靠执行”。RabbitMQ 不保证业务逻辑正确，只保证投递链路可控——剩下的，得靠你每一步的 durable、ack、retry 和 DLX 配置来填。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
