Flask的request是从哪里来的

从一个简单的 Flask 示例开始。

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def index():
    print(request.headers)
    return 'Hello World!'

if __name__ == '__main__':
    app.run()

调试程序，在客户端输入 http://localhost:5000，浏览器显示 Hello World，在 IDE 中显示了请求头的信息。看起来，request 对象像一个全局变量，导入后就可以直接使用。那么，我们将代码变一个位置：

if __name__ == '__main__':
    print(request.headers)
    app.run()

这个时候，程序出错了，抛出如下面所示的异常：

RuntimeError: Working outside of request context.

意思是 request 不在 context 之中。为什么在视图函数中可以直接使用 request，而在 app.run() 代码之前就不行呢？这就引出了一个请求上下文 (request context) 的概念。我们知道，web 程序启动后，在同一时间，可能来自多个客户端的请求，这些请求是不同的，有着各自不同的请求报文。服务器对来自不同客户端的请求，必须能够单独进行处理，互不干扰。Flask 用请求上下文 (request context) 来实现对来自不同客户端的请求能独立处理，又让开发人员在编写代码的时候，request 像一个全局变量。

那么，这个 request 是怎么来的呢？为什么在导入后就可以直接使用？本文将从代码的角度，对 Flask 背后的机制进行剖析。结合在 PyCharm 中对代码的调试和 Flask 源代码功能进行讲解。在 app.run() 语句打一个断点：

调试到该语句，变量区域显示 request 是一个 LocalProxy 对象，此时 request 的状态为 unbound，并没有跟实际来自客户端的请求绑定。

接着按 F8，我们看到，Flask 已经启动，等待客户端请求。先来看看截止这个阶段与 request 相关的代码。从 from flask import request 语句跳转到源代码。代码位于 globals.py 文件中，主要的代码如下：

# context locals
_request_ctx_stack = LocalStack()
_app_ctx_stack = LocalStack()
current_app = LocalProxy(_find_app)
request = LocalProxy(partial(_lookup_req_object, "request"))
session = LocalProxy(partial(_lookup_req_object, "session"))
g = LocalProxy(partial(_lookup_app_object, "g"))

因为有 import 语句，所以 globals.py 的代码被加载，request 被实例化。

接下来我们看看 app.run() 做了什么。如果调试该代码，就进入 Flask 类的 run() 方法。去掉 run() 方法无关的代码，该方法可以简化为：

def run(self, host=None, port=None, debug=None, load_dotenv=True, **options):
    # 去掉无关代码
    # ...
    run_simple(host, port, self, **options)

这个 run_simple 方法是 werkzeug.serving 模块提供的方法，作用是启动一个服务器。我们可以自己写一段简单代码来体验一下 werkzeug 实现的这个简单服务器：

from werkzeug.wrappers import Response, Request
from werkzeug.serving import run_simple

@Request.application
def simple_app(req):
    return Response("Hello from werkzeug!")

run_simple(hostname="127.0.0.1", port=9000, application=simple_app)

Flask 的代码复杂得多，但机制相同。

接下来，看看 Flask 如何处理来自客户端的请求。当客户端发起请求后，web server 将请求转交给后端 Flask application，此时就调用 Flask 的 __call__() 方法。Flask __call__() 方法的代码如下：

def __call__(self, environ, start_response):
    return self.wsgi_app(environ, start_response)

所以，对来自客户端的请求，会自动调用 __call__() 方法，启动 wsgi_app。下面的代码是 request 机制的核心：

def wsgi_app(self, environ, start_response):

    ctx = self.request_context(environ)  
    error = None
    try:
        try:
            ctx.push()
            response = self.full_dispatch_request()
        except Exception as e:
            error = e
            response = self.handle_exception(e)
        except:  # noqa: B001
            error = sys.exc_info()[1]
            raise
        return response(environ, start_response)
    finally:
        if self.should_ignore_error(error):
            error = None
        ctx.auto_pop(error)

与 request 相关的有两句代码：

ctx = self.request_context(environ) # 创建RequestContext实例，其中包含request
ctx.push()                          # RequestContext对象入栈

通过查看代码和调试的方式，运行机制不难理解。首先，request_context是一个函数，返回 RequestContext:

def request_context(self, environ):
    return RequestContext(self, environ)

RequestContext类的 __init__() 方法根据 environ (环境变量) 构建请求。__enter__ 和 __exit__ 方法实现了上下文管理。如果不关注更细节东西，至此基本基本可以理解请求的机制。

class RequestContext(object):
    def __init__(self, app, environ, request=None, session=None):
        self.app = app
        if request is None:
            request = app.request_class(environ)
        self.request = request
        # 其他代码略

request_class 声明在 Flask app.py 代码中，其实就是 werkzeug.wrappers.Request。

总结：Flask 通过请求上下文，自动管理每个 HTTP 请求的生命周期。当接收到客户端的请求，创建一个新的 request 对象，包含请求报文信息。当请求结束时，自动销毁请求。