请求情境¶

请求情境在请求期间跟踪请求级数据。不是将请求对象传递给在请求期间运行的每个函数，而是访问 request 和 session 代理。

这类似于应用情境，它跟踪应用程序级数据，而不受请求的影响。推送请求情境时会推送相应的应用程序情境。

情境的用途¶

当 Flask 应用处理请求时，它会根据从 WSGI 服务器收到的环境创建一个 Request 对象。因为工作者（取决于服务器的线程，进程或协程）一次只能处理一个请求，所以在该请求期间请求数据可被认为是该工作者的全局数据。 Flask 对此使用术语本地情境。

处理请求时，Flask 自动推送请求情境。在请求期间运行的视图函数，错误处理器和其他函数将有权访问 request 代理，该请求代理指向当前请求的请求对象。

情境的生命周期¶

当一个flask应用程序开始处理一个请求时，它会推送请求情境，这也会推送应用情境。当请求结束时，它会弹出请求情境，然后弹出应用程序情境。

情境对于每个线程（或其他工作者类型）是唯一的。 request 不能传递给另一个线程，另一个线程将拥有不同的情境堆栈，并且不会知道父线程指向的请求。

本地情境变量在Werkzeug中实现。有关内部如何工作的更多信息，请参阅 Context Locals 。

手动推送情境¶

如果尝试在请求情境之外访问 request 或任何使用它的东西，那么会收到这个错误消息：

RuntimeError: Working outside of request context.

This typically means that you attempted to use functionality that
needed an active HTTP request. Consult the documentation on testing
for information about how to avoid this problem.

通常只有在测试代码期望活动请求时才会发生这种情况。一种选择是使用测试客户端来模拟完整的请求。或者，可以在 with 块中使用 test_request_context() ，块中运行的所有内容都可以访问请求，并填充测试数据。:

def generate_report(year):
    format = request.args.get('format')
    ...

with app.test_request_context(
        '/make_report/2017', data={'format': 'short'}):
    generate_report()

如果在代码中的其他地方看到与测试无关的错误，则很可能表明应该将该代码移到视图函数中。

有关如何使用来自交互python shell的请求情境的信息，请参见在Shell中使用Flask .

情境如何工作¶

处理每个请求时都会调用 Flask.wsgi_app() 方法。它在请求期间管理情境。在内部，请求和应用程序情境实质是 _request_ctx_stack 和 _app_ctx_stack 堆栈。当情境被压入堆栈时，依赖它们的代理可用并指向堆栈顶部情境中的信息。

当请求开始时，将创建并推送 RequestContext ，如果该应用程序的情境尚不是顶级情境，则该请求会首先创建并推送 AppContext 。在推送这些情境时，current_app 、 g 、 request 和 session 代理可用于处理请求的原始线程。

由于情境是堆栈，因此在请求期间可能会压入其他情境导致代理变更。虽然这不是一个常见的模式，但它可以用于高级应用程序，例如，进行内部重定向或将不同的应用程序链接在一起。

在发送请求并生成和发送响应之后，将弹出请求上下文，然后弹出应用程序上下文。在它们被弹出之前， teardown_request() 和 teardown_appcontext() 执行函数。即使在调度过程中发生未处理的异常，也会执行这些操作。

回调和错误¶

Flask 会在多个阶段调度请求，这会影响请求，响应以及如何处理错误。情境在所有这些阶段都处于活动状态。

Blueprint 可以为这些特定于蓝图的事件添加处理程序。如果蓝图拥有与请求匹配的路由，则蓝图的处理程序将运行。

在每次请求之前，before_request() 函数都会被调用。如果其中一个函数返回了一个值，则其他函数将被跳过。返回值被视为响应，并且视图函数不会被调用。
如果`before_request` 函数没有返回响应，将调用匹配路由的视图函数并返回响应。
视图的返回值将转换为实际响应对象并传递给 after_request 函数。每个函数都返回一个已修改或新的响应对象。
返回响应后，将弹出情境，该情境调用 teardown_request() 和 teardown_appcontext() 函数。即使在上面任何一处引发了未处理的异常，也会调用这些函数。

如果在拆卸函数之前引发异常，则Flask将尝试将其与 errorhandler 函数进行匹配来处理异常并返回响应。如果找不到错误处理程序，或者处理程序本身引发异常，则flask返回一个通用的 500 Internal Server Error 反应。TearDown函数仍然被调用，并被传递给异常对象。

如果启用了调试模式，则未处理的异常不会转换为 500 响应，而是会传播到 WSGI 服务器。这允许开发服务器向交互式调试器提供回溯。

拆卸回调¶

拆除回调与请求派发无关，而在情境弹出时由情境调用。即使在调度过程中出现未处理的异常，以及手动推送的情境，也会调用这些函数。这意味着不能保证请求调度的任何其他部分都先运行。一定要以不依赖其他回调的方式编写这些函数，并且不会失败。

在测试期间，延迟在请求结束后弹出上下文是很有用的，这样就可以在测试函数中访问上下文的数据。使用 test_client() 作为一个 with 块以保留上下文，直到 with 封锁出口。

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def hello():
    print('during view')
    return 'Hello, World!'

@app.teardown_request
def show_teardown(exception):
    print('after with block')

with app.test_request_context():
    print('during with block')

# teardown functions are called after the context with block exits

with app.test_client() as client:
    client.get('/')
    # the contexts are not popped even though the request ended
    print(request.path)

# the contexts are popped and teardown functions are called after
# the client with block exits

信号¶

如果 signals_available 为真，将发送以下信号：

request_started 发送于 before_request() 函数被调用之前。
request_finished 发送于 after_request() 函数被调用之后。
got_request_exception 发送于异常开始处理的时候但早于 an errorhandler() 被找到或者调用的时候。
request_tearing_down 发送于 teardown_request() 函数被调用之后。

出错情境保存¶

在请求结束时，会弹出请求情境，并且与其关联的所有数据都将被销毁。如果在开发过程中发生错误，延迟销毁数据以进行调试是有用的。

当开发服务器以开发模式运行时（ FLASK_ENV 环境变量设置为 'development' ），将保留错误和数据并显示在交互式调试器中。

该行为可以通过 PRESERVE_CONTEXT_ON_EXCEPTION 配置进行控制。如前文所述，它在开发环境中默认为 True 。

不要在生产环境中启用 PRESERVE_CONTEXT_ON_EXCEPTION ，因为它会导致应用在发生异常时泄漏内存。

代理须知¶

Flask 提供的一些对象是其他对象的代理。每个工作线程都能以相同的方式访问代理，但是在后台每个工作线程绑定了唯一对象。如本页所述。

大多数情况下，您不必关心这个问题，但也有一些例外情况，知道这个对象实际上是一个代理是很好的：

代理对象不能将其类型伪装为实际的对象类型。如果要执行实例检查，则必须在被代理的对象上执行该操作。
在某些情况下需要对代理对象的引用，例如发送信号或者将数据传递到后台线程。

如果您需要访问被代理的源对象，请使用 _get_current_object() 方法:

app = current_app._get_current_object()
my_signal.send(app)