长话短说，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'