必须用 lifespan 而非 on_event 初始化 RabbitMQ 连接，因 lifespan 是原生异步上下文管理器，确保连接池和通道池就绪后才接收请求；on_event 为同步钩子包装的协程，不等待初始化完成即放行请求，易致首几个请求抛出 ConnectionRefusedError 或 ChannelClosed。
直接用 lifespan 管理 rabbitmq 连接，别再碰 @app.on_event("startup") —— 它无法保证异步资源初始化完成后再接收请求，容易在首几个请求里抛出 connectionrefusederror 或 channelclosed。
为什么必须用 lifespan 而不是 on_event？
FastAPI 的 on_event 是同步钩子包装的协程，启动阶段不等待协程真正完成就放行请求；而 lifespan 是原生异步上下文管理器，yield 之前的所有 await 都会阻塞到完成，确保连接池、通道池就绪后才进服务状态。
常见错误现象：
– 启动后前 2~3 个请求失败，日志显示 aio_pika.exceptions.AMQPConnectionError
– 关闭时连接未释放，Docker 日志里持续报 Connection closed by remote
-
lifespan中初始化的connection_pool和channel_pool可通过request.app.state全局共享，避免每次请求都新建连接 -
on_event下的await connection.connect()实际是“火种扔出去就不管”，没等握手完成就返回了 - 如果你用了
aio-pika，它的RobustConnection自带重连，但前提是首次连接成功——这一步只能靠lifespan保底
怎么写一个可靠的 RabbitMQ lifespan？
核心是两件事：连接池复用 + yield 后的显式关闭。不要手写 connect/close，交给 aio-pika 的 Pool 和 RobustConnection。
示例关键片段：
from contextlib import asynccontextmanager
from aio_pika import connect_robust, RobustConnection
from aio_pika.pool import Pool
<p>async def get_connection() -> RobustConnection:
return await connect_robust("amqp://guest:guest@localhost/")</p><p>connection_pool = Pool(get_connection, max_size=4)</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/gongju/2255" title="RabbitMQ 4.2.3"><img
src="https://img.php.cn/upload/manual/001/246/273/6a0d624e43a18976.png" alt="RabbitMQ 4.2.3" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/gongju/2255" title="RabbitMQ 4.2.3">RabbitMQ 4.2.3</a>
<p>RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。</p>
</div>
<a href="/xiazai/gongju/2255" title="RabbitMQ 4.2.3" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p>@asynccontextmanager
async def lifespan(app: FastAPI):</p><h1>启动：预热连接池（触发首次连接）</h1><pre class="brush:php;toolbar:false;">async with connection_pool:
yield
# 关闭：Pool.__aexit__ 会自动 close 所有连接
- 不用手动调
await connection.close()，Pool的上下文退出会批量清理 -
max_size别设太大（建议 2–6），RabbitMQ 单连接能支撑多路 channel，过量连接反而触发 broker 限流 - 如果需要 channel 级复用，再套一层
channel_pool = Pool(get_channel, max_size=16)，但注意get_channel必须从connection_pool里取连接
连接字符串和重连行为怎么配才稳？
RabbitMQ 连接字符串里的参数直接影响首次连接成功率和断线恢复能力，尤其在 Docker 重启或网络抖动时。
推荐连接 URL 格式：
amqp://guest:guest@rabbitmq:5672/?connection_attempts=3&retry_delay=2&heartbeat=30
-
connection_attempts=3：启动时最多重试 3 次，避免因 broker 启动慢导致 FastAPI 直接 crash -
retry_delay=2：每次重试间隔 2 秒，配合connection_attempts控制总等待时间 -
heartbeat=30：开启心跳，防止 NAT 或负载均衡器超时断连；值太小（如 5）可能引发频繁重连 - 生产环境务必换掉
guest用户，用vhost隔离：amqp://user:pass@rabbitmq:5672/my_vhost
最容易被忽略的是：连接池初始化本身不触发真实连接，第一次 acquire 才真正拨号。所以 lifespan 里得用 async with connection_pool 主动预热一次，否则第一个请求仍可能失败。
