长话短说，Flask没有提供任何特殊功能来完成此任务。对于简单的一次性任务，请考虑使用Python的多线程，如下所示。对于更复杂的配置，请使用任务队列，例如RQ或Celery。
为什么？
重要的是要了解Flask提供的功能以及为什么它们无法实现预期的目标。所有这些都在其他情况下很有用，并且很好阅读，但对后台任务没有帮助。
Flask的
after_request处理者
Flask的
after_request处理程序（如本模式中有关延迟的请求回调的详细说明）以及有关每个请求附加不同功能的代码段，会将请求传递给回调函数。预期的用例是修改请求，例如附加cookie。
因此，请求将等待这些处理程序完成执行，因为期望结果是请求本身将发生更改。
Flask的
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'
