长话短说，Flask没有提供任何特殊功能来完成此任务。对于简单的一次性任务，请考虑使用Python的多线程，如下所示。对于更复杂的配置，请使用任务队列，例如RQ或Celery。
为什么？
重要的是要了解Flask提供的功能以及为什么它们 无法 实现预期的目标。所有这些在其他情况下都很有用，并且很好阅读，但是对后台任务没有帮助。
烧瓶的after_request
处理者
Flask的
after_request处理程序（如本模式中有关延迟的请求回调的详细说明）以及有关每个请求附加不同功能的代码段，会将请求传递给回调函数。预期的用例是
修改请求 ，例如附加cookie。
因此，该请求将等待这些处理程序完成执行，因为期望该请求本身将因此而发生变化。
烧瓶的teardown_request
处理者
这类似于
after_request，但
teardown_request不接收
request对象。这样就意味着它不会等待请求，对吗？
这似乎是解决方案，因为对类似的堆栈溢出问题的答案表明了这一点。并且由于Flask的文档说明了拆解回调与实际请求无关，并且未接收到请求上下文，因此您很有理由相信这一点。
不幸的是，
teardown_request它仍然是同步的，它只是在Flask的请求处理的后半部分发生，当请求不再可修改时。Flask在返回响应之前
仍会等待拆卸功能
完成，因为此清单包含Flask回调和错误。
Flask的流式响应
Flask可以通过将生成器传递给来流式传输响应
Response()，这是对类似问题的堆栈溢出答案所暗示的。
使用流传输时，客户端 确实会 在请求结束之前开始接收响应。但是，请求仍然是同步运行的，因此处理请求的工作人员很忙，直到流完成。
这种用于流式传输的Flask模式包括一些有关using的文档
stream_with_context()，这对于包括请求上下文是必不可少的。
那么解决方案是什么？
Flask不提供在后台运行功能的解决方案，因为这不是Flask的责任。
在大多数情况下，解决此问题的最佳方法是使用任务队列，例如RQ或Celery。这些为您管理诸如配置，计划和分配工作人员之类的棘手事情，这是此类问题最常见的答案，因为它是最正确的，并迫使您以考虑上下文的方式进行设置。正确地。
如果您需要在后台运行一个函数，并且不想建立一个队列来管理该函数，则可以使用Python的内置函数
threading或
multiprocessing生成一个后台工作器。
您无法
request从后台任务访问Flask的其他线程本机，也无法访问其他Flask的线程本机，因为该请求在该处不会处于活动状态。而是在创建数据时将所需的数据从视图传递到后台线程。
@app.route('/start_task')def start_task(): def do_work(value): # do something that takes a long time import time time.sleep(value) thread = Thread(target=do_work, kwargs={'value': request.args.get('value', 20)}) thread.start() return 'started'
