flask路由中直接调用耗时函数会导致请求阻塞，因其默认单线程同步模型；多线程适用于轻量异步操作但无法访问flask上下文；celery是生产环境可靠异步任务标准，需消息中间件与正确上下文处理。
Flask路由里直接调用耗时函数会导致请求阻塞
Flask 默认是单线程同步模型，app.run() 启动的开发服务器在收到请求后，会用同一个工作线程执行视图函数。如果视图里调用了耗时操作（比如网络请求、文件处理、复杂计算），整个线程会被卡住，后续请求排队等待——用户看到的是响应延迟甚至超时，504 Gateway Timeout 或浏览器“转圈”不动。
这不是代码写得“不够快”的问题，而是架构层面的阻塞。强行加 time.sleep(5) 就能复现：一个请求进来，5 秒内其他所有请求都卡死。
多线程适合轻量、短时、不依赖 Flask 上下文的操作
用 threading.Thread 或 concurrent.futures.ThreadPoolExecutor 把耗时逻辑扔进后台线程，能让主线程快速返回 HTTP 响应。但要注意：线程无法直接访问 request、session、g 等 Flask 上下文对象，因为它们是线程局部的（thread-local）。
- 必须提前提取所需数据（如
request.json、request.args.get('id')），传给线程函数 - 不能在线程里调用
url_for()、render_template()或操作数据库 session（除非显式创建新 session） - 线程中抛出的异常不会被 Flask 捕获，需手动记录日志，否则悄无声息失败
- 适合场景：发一封邮件、调用一次外部 API、生成小文件、触发本地脚本
示例：
from concurrent.futures import ThreadPoolExecutor
executor = ThreadPoolExecutor(max_workers=4)
<p>@app.route('/notify')
def send_notify():
user_id = request.args.get('user_id')</p><h1>提前取值，不传 request 对象</h1><pre class="brush:php;toolbar:false;"><pre class="brush:php;toolbar:false;">executor.submit(send_email_async, user_id)
return {'status': 'queued'}Celery 是生产环境异步任务的事实标准
当任务需要可靠性、重试、定时、结果查询或跨进程/机器分发时，Celery
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
关键点：
- 必须配置消息中间件（
redis或rabbitmq），celery本身不存任务队列 - Flask 应用里定义任务要用
@celery.task装饰器，且 task 函数不能依赖 Flask 上下文（同多线程） - 启动 worker 命令是
celery -A tasks.celery worker --loglevel=info，不是跑app.run() - 任务结果默认不持久化，要查结果需启用
result_backend（如 Redis）并调用task_id.get()
常见错误：RuntimeError: Working outside of application context —— 因为在 task 函数里写了 current_app.config 或 db.session.add()。正确做法是：在 task 内重新初始化数据库连接，或把 db 操作逻辑移到 task 外部、只传 ID 进去。
别忽略前端配合和用户反馈
异步不是“看不见就等于没发生”。用户点击提交后，如果立刻返回 “已提交”，但实际任务失败了，他永远不会知道。
- 返回一个唯一的
task_id，前端用它轮询/task-status/<id></id>接口获取进度或结果 - 对长时间任务（>30s），考虑用 WebSocket 或 Server-Sent Events 主动推送，而不是暴力轮询
- 任务失败时，记录详细错误（包括 traceback）、输入参数、时间戳，方便排查；不要只存
"failed" - 避免让用户反复点击触发重复任务：前端按钮点击后置灰，或服务端用
cache.set(f"task:{key}", True, timeout=60)做简单幂等控制
最常被跳过的环节是错误归因——你以为是 Celery 配置错了，结果发现是 Redis 密码没配对，或者任务函数里忘了加 import。先确保 celery -A tasks inspect ping 能通，再动业务逻辑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
