Flask中发消息到RabbitMQ不卡请求的关键是复用连接与通道、使用JSON序列化、设置delivery_mode=2和durable=True；消费者须独立进程、auto_ack=False、手动ack、qos限流、异常nack重试；生产环境必配disk_free_limit、启用management插件、禁用guest账户、显式指定vhost。
Flask里怎么发消息到RabbitMQ，不卡住请求
关键不是“能不能发”，而是“发完立刻返回”，否则用户注册、上传文件时要干等几秒。用 pika.BlockingConnection 直接在 Flask 路由里发消息，看似简单，但每次新建连接+通道开销大，高并发下容易耗尽 socket 或触发 RabbitMQ 连接限制。
- 必须把连接和通道复用起来——别在每次请求里
pika.BlockingConnection(...)，改用单例或应用上下文初始化一次 - 消息体建议用 JSON 字符串（如
json.dumps({"user_id": 123, "action": "send_welcome"})），别传裸字符串，方便消费者解析和未来扩展 - 一定要设
delivery_mode=2，否则消息不持久化，RabbitMQ 重启就丢；同时队列声明要加durable=True - 别用
auto_ack=True发送端——那是消费者参数，发消息不涉及 ack
示例片段（非完整 app）：
import pika
import json
<h1>全局复用连接（启动时建立）</h1><p>connection = pika.BlockingConnection(pika.URLParameters("amqp://guest:guest@localhost:5672/"))
channel = connection.channel()
channel.queue_declare(queue="email_tasks", durable=True)</p><p>def send_email_task(user_id: int):
payload = json.dumps({"user_id": user_id, "template": "welcome"})
channel.basic_publish(
exchange="",
routing_key="email_tasks",
body=payload,
properties=pika.BasicProperties(delivery_mode=2) # ← 必加
)消费者进程怎么写才不丢任务、不重复消费
很多人写完生产者就直接在 Flask 里写个 channel.start_consuming()，结果发现：服务一重启，消息全没了；或者消费者崩溃后，同一条消息被多个进程反复处理。
- 消费者必须独立于 Flask Web 进程运行（比如另起一个
worker.py），否则 Gunicorn reload 会杀掉它 -
basic_consume一定要配auto_ack=False，并在业务逻辑成功后再手动调用ch.basic_ack(delivery_tag=method.delivery_tag) - 加
channel.basic_qos(prefetch_count=1)，防止一个 Worker 预取太多任务却卡死，导致其他 Worker 饿着 - 捕获异常后别吞掉，至少要
ch.basic_nack(..., requeue=True)，让失败任务重回队列尾部重试
典型错误现象：ChannelClosedByBroker: (406) PRECONDITION_FAILED —— 往非 durable 队列发了 durable 消息，或反过来。
立即学习“Python免费学习笔记（深入）”；
RabbitMQ配置哪些项不能省，否则上线就出问题
本地跑通不等于生产可用。很多团队跳过这步，结果压测时连接数暴涨、消息堆积、甚至磁盘爆满。
- 必须启用
disk_free_limit（默认是 1GB），不然磁盘写满后 RabbitMQ 会拒绝所有写入，整个系统静默失败 - Web 管理界面默认关闭，上线前要确认
rabbitmq-plugins enable rabbitmq_management并设好防火墙规则 - 别用
guest/guest登录生产环境——创建专用用户并赋予权限：rabbitmqctl add_user myapp pwd && rabbitmqctl set_permissions myapp ".*" ".*" ".*" - 如果用 Docker 部署，
RABBITMQ_DEFAULT_USER和RABBITMQ_DEFAULT_PASS环境变量只在首次启动生效，后续改密码得进容器执行命令
Flask + RabbitMQ 和 Celery 到底选哪个
这不是“高级 vs 简单”的选择，而是“自己管流程” vs “交给框架管”。如果你只需要发邮件、导 Excel 这类固定任务，Celery 的 @celery.task 确实省心；但如果你要做老照片修复、AI 推理这类长时任务，且需自定义重试策略、优先级路由、或对接 ComfyUI 工作流，那直接用 pika 控制更灵活。
- Celery 默认用 Redis 做 Broker 更轻量，换 RabbitMQ 要装
celery[librabbitmq]并注意心跳配置，否则空闲连接会被中间设备断开 - Flask 中硬集成 pika 的好处是：完全掌控连接生命周期、可做细粒度错误分类（比如网络超时 vs 队列满）、能按业务打标（如用不同 routing_key 区分紧急/普通任务）
- 容易被忽略的点：RabbitMQ 的 virtual host（vhost）必须显式指定在 URL 里，比如
amqp://user:pass@host:5672/myvhost，漏掉就连到/下，权限和队列都对不上
真正麻烦的从来不是“怎么连上”，而是“消息发出去后，谁来保证它被正确执行完、失败了怎么通知、积压了怎么告警”——这些得靠监控、日志、重试机制和人工巡检兜底。
