flask上下文全局变量，程序上下文、请求上下文、上下文钩子

Flask上下文

Flask中有两种上下文，程序上下文（application context）和请求上下文（request context）

当客户端发来请求时，请求上下文就登场了。请求上下文里包含了请求的各种信息，比如请求的URL，请求的HTTP方法等。

上下文全局变量

视图函数需要上下文信息，flask将请求报文封装在request对象中，但是在视图函数中，并没有把它传进视图函数，而是直接从Flask导入一个全局的request对象，然后在视图函数里直接调用request的属性获取数据。为什么在处理请求时，视图函数里的request会自动包含对应请求的数据呢？ 因为flask在每个请求产生后自动激活当前请求的上下文，激活请求上下文后，request被临时设为全局可访问 。当每个请求结束后，flask就销毁对应的请求上下文。

我们在前面说request是全局对象，但这里的全局并不是实际意义上的全局。我们把这些变量理解为动态的全局变量。

在多线程服务中，在同一时间可能会有多个请求在处理。假设有三个客户端同时向服务器发送请求，这时每个请求都有各自不同的请求报文，所以请求对象必然是不同的。

因此，请求对象只在各自的线程内是全局的。flask通过本地线程（thread local）技术将请求对象在特定的线程和请求中全局可访问。

为了方便获取这两种上下文环境那种存储的信息，flask提供了四个上下文全局变量

在不同的视图函数中，request对象都表示和视图函数对应的请求，就是当前请求（current request）。程序会有多个程序实例的情况，为了能获取对应的程序实例，而不是固定的某一个程序实例，我们就需要使用current_app变量。

g存储在程序上下文中，而程序上下文会随着每一个请求的进入而激活，随着每一个请求的处理完毕而销毁，所以每次请求都会重设这个g值。

我们通常会使用它结合钩子来保存每个请求处理前所需要的全局变量。

当请求进入时，flask会自动激活请求上下文，这时可以使用request和session变量。当请求上下文被激活时，程序上下文也被自动激活。

除了上面四个上下文变量，依赖上下文的还有url_for()和jsonify()函数，所以只能在视图函数中使用它们。其中jsonify()函数内部调用中使用了current_app变量，url_for()则需要依赖请求上下文才可以正常运行。

程序上下文可以用with语句执行操作

程序上下文也可以显示地使用push()方法推送（激活），在执行完操作后，用pop()方法销毁上下文

请求上下文可以通过test_request_context()方法临时创建

同样的，这里也可以使用push()和pop()方法显示地激活和销毁上下文

上下文钩子（回调函数）

flask为上下文提供了一个teardown_appcontext钩子，使用它注册的毁掉函数会在程序上下文被销毁时调用，通常也在请求上下文被销毁时调用，比如你需要在每个请求处理结束后销毁数据库连接：

@app.teardown_appcontext

def teardown_db(exception):

    db.close()

app.reardown_appcontext装饰器注册的回调函数需要接收异常对象作为参数，当请求被正常处理时这个参数将是None，这个函数的返回值将被忽略