直接用 aio-pika 的 connect_robust() 会卡住，因其默认等待 DNS 解析完成，而 asyncio 对阻塞式 DNS 处理有缺陷；高并发下 channel.declare_queue() 报 ChannelClosed 是因 Channel 非协程安全，需独占实例或用 async with 隔离生命周期。
为什么直接用 aio-pika 的 connect_robust() 会卡住？
不是连接慢，是它默认等待 DNS 解析完成才返回 —— 如果你用的是容器内网或自定义 hosts，connect_robust() 可能卡在 getaddrinfo 上几秒甚至超时。这不是 bug，是 asyncio 默认事件循环对阻塞式 DNS 的处理缺陷。
- 改用
connect()+ 手动传解析后的 IP（比如host="10.0.2.5"），跳过 DNS - 或者提前调用
asyncio.get_event_loop().set_exception_handler(...)捕获socket.gaierror并 fallback - 更稳妥的做法：启动时用
socket.gethostbyname()同步解析一次，缓存结果，后续全走 IP 连接
channel.declare_queue() 为什么在高并发下报 ChannelClosed？
因为 aio-pika 的 Channel 不是线程安全，也不是协程安全的 —— 多个 await 同时调用同一个 channel 实例，底层 AMQP 帧序会乱，RabbitMQ 主动关闭通道。
- 每个 consumer 或 producer 逻辑，应独占一个
channel实例（不要复用） - 用
async with connection.channel() as channel:确保生命周期隔离 - 如果要并发发消息，别用同一个
channel.basic_publish()，改用connection.publish()（它内部自动分配临时 channel）
如何让 aio-pika 消费不丢消息又不重复？
关键不在 auto_ack=False，而在于 basic_qos() 和手动 ack() 的时机是否匹配业务处理边界。RabbitMQ 不知道你的 handler 是同步还是异步、会不会崩溃、会不会 await 耗时太久。
- 必须设
await channel.basic_qos(prefetch_count=1)，否则 RabbitMQ 会批量推多条，worker 挂掉就丢 -
ack()必须放在try/except的finally里，且只在业务逻辑真正完成后再发（不能在收到后立刻 ack） - 如果 handler 内部有
await asyncio.sleep(10)这类长耗时操作，记得给 RabbitMQ 发channel.basic_nack(requeue=True)+ 设置delivery_tag超时重投，否则消息会被锁死
为什么 asyncio.run(main()) 退出后 RabbitMQ 连接没干净断开？
因为 aio-pika 的 Connection 和 Channel 都实现了 __aexit__，但 asyncio.run() 强制 cancel 所有 pending task，导致 close() 协程根本没机会执行，TCP 连接处于 FIN_WAIT2 状态，RabbitMQ 认为客户端异常下线。
立即学习“Python免费学习笔记（深入）”；
- 别用
asyncio.run()做长期服务入口；改用loop.run_until_complete(main())+ 显式loop.run_until_complete(connection.close()) - 加信号监听（如
signal.signal(signal.SIGTERM, ...)），在退出前 await 关闭 connection - 生产环境务必设
connection.close_timeout = 5，避免 shutdown 卡死
最常被忽略的点：RabbitMQ 的 heartbeat 默认是 60 秒，但 aio-pika 的心跳检测依赖 event loop 正常运转 —— 如果你的 consumer 里写了阻塞代码（比如 time.sleep()），心跳帧发不出去，连接会被服务器强制断开，且不会抛异常，只会静默重连失败。
