靠默认配置发消息必然丢消息；必须同时启用发布确认、设置delivery_mode=2持久化消息、关闭auto_ack并手动ACK，再配合合理心跳与连接重建机制。
直接说结论：靠默认配置发消息，基本等于“发完就不管”，丢消息是常态；真要可靠，必须同时控制三件事——连接心跳、消息持久化、手动 ACK。
为什么pika.BlockingConnection默认不保消息
很多人一上来就写pika.BlockingConnection(pika.ConnectionParameters('localhost'))，连上就发，结果服务重启或网络抖动后消息全丢。根本原因是：pika默认不启用发布确认（publisher confirms），也不强制消息落盘，更不校验消费者是否真正处理成功。
- 消息发出去后，RabbitMQ只保证“进了自己的内存缓冲区”，没写磁盘就宕机 → 消息消失
- 消费者收到消息后，
auto_ack=True（默认）→ RabbitMQ立刻删消息，哪怕消费者中途崩溃 - 连接空闲超时（默认30秒）→ TCP断开，未确认消息被丢弃，且客户端无感知
basic_publish里必须设delivery_mode=2才持久化
光把队列声明成持久化（durable=True）远远不够。消息本身也得标为持久化，否则进不了磁盘。这个动作发生在basic_publish调用时，靠properties参数控制。
- 错误写法：
channel.basic_publish(exchange='', routing_key='q1', body='msg')→ 消息仅存内存 - 正确写法：
channel.basic_publish(exchange='', routing_key='q1', body='msg', properties=pika.BasicProperties(delivery_mode=2)) - 注意：
delivery_mode=2不是 magic number，它是 AMQP 协议定义的常量，别写成字符串或 1 - 副作用：频繁写磁盘会略降吞吐，但 Web 应用通常更看重可靠性而非峰值 QPS
消费者必须关掉auto_ack并手动basic_ack
Web 应用里消费者往往是 Flask/FastAPI 的后台任务进程，处理逻辑可能涉及数据库写入、HTTP 调用等，耗时不可控。一旦用auto_ack=True，RabbitMQ 在投递瞬间就删消息，后续出错就彻底丢失。
立即学习“Python免费学习笔记（深入）”；
- 声明队列时加
durable=True，消费时显式关掉自动确认：channel.basic_consume(queue='q1', on_message_callback=callback, auto_ack=False) - 在 callback 函数里，只有业务逻辑全部跑完、没异常，才调
channel.basic_ack(delivery_tag=method.delivery_tag) - 如果 callback 抛异常，别 catch 后 silence —— 让它冒泡，或者显式调
channel.basic_nack触发重试/死信 - 漏掉
basic_ack会导致消息卡在 unacked 状态，堆积后拖慢整个队列
心跳和连接重建比想象中更关键
Web 应用常部署在容器或云环境，NAT 网关、负载均衡器普遍 5–10 分钟断空闲连接。RabbitMQ 默认心跳是 60 秒，但很多中间设备不转发心跳包，导致连接静默断开。
- 连接参数里必须设
heartbeat=30（甚至更低），并配blocked_connection_timeout=300 -
BlockingConnection不支持自动重连，得自己套一层 try/except + 循环重建 connection/channel - 别复用全局 connection 实例 —— 多线程/多 worker 下会冲突，每个请求/任务应独占 channel
- FastAPI 的 background task 或 Celery worker 中，建议用 context manager 封装 connection 生命周期
真正难的不是写那几行basic_publish，而是把连接生命周期、消息状态流转、失败边界这三件事串成闭环。少一个环节，就等于在生产环境埋雷。
