RabbitMQ可靠性需五层叠加：连接管理、队列声明、消息属性、发布确认、消费确认；漏任一层都可能在高并发或网络抖动时导致消息丢失或重复。
发送消息前必须确认连接和通道已正确建立
直接调用 channel.basic_publish() 却没检查连接状态，是脚本静默失败的最常见原因。pika 的连接默认不自动重连，BlockingConnection 在网络中断后不会恢复，必须手动处理异常并重建。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 始终用
try/except pika.exceptions.AMQPConnectionError包裹连接逻辑，捕获底层断连 - 发送前加
if connection.is_open and channel.is_open:双重校验，避免“连接看似存在实则失效” - 不要复用全局
connection或channel实例跨多线程 —— pika 的BlockingConnection不是线程安全的 - 示例片段：
try: connection = pika.BlockingConnection(params) channel = connection.channel() channel.queue_declare(queue='task_queue', durable=True) channel.basic_publish( exchange='', routing_key='task_queue', body='hello', properties=pika.BasicProperties(delivery_mode=2) # 持久化消息 ) except pika.exceptions.AMQPConnectionError: print("RabbitMQ 连接失败，请检查服务是否运行")
消费端必须显式调用 channel.start_consuming() 并处理退出逻辑
写完 channel.basic_consume() 就以为队列开始工作了？不会。它只是注册回调，真正启动循环消费靠 start_consuming() —— 而且这个调用是阻塞的，没有它，脚本立即退出。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把
start_consuming()放在try/finally块里，确保中断时能关闭连接：try: channel.start_consuming() except KeyboardInterrupt: channel.stop_consuming() finally: connection.close() - 如果需要优雅退出（比如收到 SIGTERM），不能只靠
KeyboardInterrupt；要注册信号处理器，调用channel.stop_consuming() - 回调函数中务必调用
ch.basic_ack(delivery_tag=method.delivery_tag)，否则消息会一直留在 Ready 状态，且可能被重复投递（取决于 no_ack 设置）
delivery_mode=2 和 durable=True 必须同时设置才真正持久化
只设 queue_declare(durable=True)，但发消息时不加 properties=pika.BasicProperties(delivery_mode=2)，消息依然会丢失 —— RabbitMQ 只对“队列 + 消息”双持久才保证重启后不丢。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 生产环境所有关键消息都应启用双重持久化，哪怕有轻微性能损耗
-
delivery_mode=1是非持久（内存存储），=2才写磁盘；别依赖默认值，必须显式指定 - 注意：即使持久化，RabbitMQ 仍可能在写入磁盘前崩溃而丢失最后几条消息；如需强一致性，需开启 publisher confirms（见下一点）
高可靠性场景必须启用 publisher confirms 并检查返回
默认的 basic_publish() 是“发了就忘”，网络丢包或 broker 拒收都不会报错。要确认消息真进队列，得开 confirm 模式。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 创建 channel 后立刻调用
channel.confirm_delivery() - 用
channel.basic_publish(..., mandatory=True)配合return_callback处理未路由消息 - 更稳妥的做法是同步等待确认：
channel.confirm_delivery() if channel.basic_publish(...): print("消息已确认入队") else: print("消息被 broker 拒绝或超时") - 注意：启用 confirm 后性能下降明显，QPS 会降低，别在低延迟要求的实时日志推送中滥用
RabbitMQ 的可靠性不是靠单个参数开关实现的，而是连接管理、队列声明、消息属性、发布确认、消费确认这五层叠加的结果。漏掉任何一层，都可能在流量高峰或网络抖动时暴露问题。
