必须调大心跳间隔并确保客户端能主动发心跳，pika 0.10+ 版本仅支持整数型heartbeat参数，需设为略大于最长任务耗时的值（如300秒），并在耗时操作中调用connection.sleep(0)触发心跳，断连后需捕获异常重建连接并重置消费，同时依赖幂等设计防重复或丢失。
必须调大心跳间隔并确保客户端能主动发心跳，光改超时参数没用，pika 0.10+ 版本不认 blocked_connection_timeout 这类旧参数。
为什么连接会在任务中途被RabbitMQ单方面关闭
不是网络断了，是 RabbitMQ 服务端判定客户端“失联”：它每 heartbeat 秒发一次心跳包，若连续两次（即 2 * heartbeat 秒）没收到响应，就直接断连。Python 的 pika.BlockingConnection 在执行耗时任务（比如 30 分钟数据库导入）时，线程被阻塞，根本没法回心跳——服务端等不及就 kill 掉连接。
- 默认
heartbeat=60，意味着最多空闲 120 秒就会断连 - 你代码里写的
connection_timeout=30000是建立连接阶段的超时，对已建连后的保活无效 -
socket_timeout、heartbeat_interval等参数在 pika 0.10.0+ 已废弃，传进去直接报TypeError: __init__() got an unexpected keyword argument
pika 正确设置心跳的写法（适配 0.10.0+）
新版 pika 只认 heartbeat 参数，且必须设为整数（单位：秒），不能是字符串或浮点数。值设太小没用，设太大可能被服务端拒绝（取决于 RabbitMQ 配置的 heartbeat 上限）。
- 先查 RabbitMQ 实际允许的最大心跳：
rabbitmqctl environment | grep heartbeat，常见上限是 600 秒 - 连接参数中显式传
heartbeat=300（5 分钟），比你的最长单任务耗时略大即可 - 不要设
0关闭心跳——部分 RabbitMQ 版本会强制启用最小值（如 10 秒），反而更不稳定 - 示例代码：
import pika
credentials = pika.PlainCredentials('user', 'pass')
params = pika.ConnectionParameters(
host='localhost',
port=5672,
virtual_host='/',
credentials=credentials,
heartbeat=300 # ← 关键，必须是 int
)
connection = pika.BlockingConnection(params)
channel = connection.channel()
耗时任务中手动触发心跳（防阻塞失联）
即使设了 heartbeat=300，只要你的消费逻辑卡在 channel.basic_consume() 之后、又没调用任何 channel 方法，心跳就不会发。pika 的心跳检测只发生在「调用 channel 或 connection 方法时」。
- 在长时间循环或数据库操作前后，加一句
connection.sleep(0)—— 这会强制检查并发送心跳 - 或者定期调用
channel.queue_declare(..., passive=True)（轻量元数据查询，不改动队列） - 绝对不要依赖
time.sleep()纯等待，它不会触发心跳逻辑 - 如果你用的是
basic_qos(prefetch_count=1)，记得在任务开始前就设置好，避免消息堆积压垮 channel
连接断开后如何安全恢复而不丢消息
心跳失效导致断连时，未 ack 的消息会自动重回队列（前提是没设 auto_ack=True）。但你的消费者进程还在跑，只是 channel 失效了——此时继续调 channel.basic_ack() 会抛 ChannelClosedByBroker 异常。
立即学习“Python免费学习笔记（深入）”；
- 必须用 try/except 包住整个消费逻辑，捕获
pika.exceptions.AMQPConnectionError和pika.exceptions.ChannelClosedByBroker - 异常后不要直接
continue，要重建connection和channel，再重新basic_consume() - 关键：重建前加
time.sleep(1)，避免快速重连触发 RabbitMQ 的连接频率限制 - ack 动作必须放在 try 块内，且确认消息处理成功后再 ack，否则重连后重复消费
真正麻烦的不是断连本身，而是断连后你的 ack 状态和事务边界是否清晰——比如数据库已提交但没来得及 ack，下次重连就会重复消费；或者 ack 了但数据库 rollback 了，消息就丢了。心跳只是保活手段，最终得靠幂等设计兜底。
