flask框架(下)

werkzeug简介

Werkzeug是一个WSGI工具包，他可以作为一个Web框架的底层库。这里稍微说一下， werkzeug 不是一个web服务器，也不是一个web框架，而是一个工具包，官方的介绍说是一个 WSGI 工具包，它可以作为一个 Web 框架的底层库，因为它封装好了很多 Web 框架的东西，例如 Request，Response 等等

通过 查看 flask.run() 源码可以发现，实际上执行的也是 werkzeug 下的 run_simlpe 函数

如下一个demo 可以看出 run_simple() 做了些什么

from werkzeug.serving import run_simple
from werkzeug.wrappers import Request, Response@Request.application
def app(req):print(req.method)    # GETprint(req.path)     # /return Response('200 ok')run_simple('0.0.0.0', 5000, app)

请求上下文

在django 中，每一个试图函数，都必需要接受一个request参数，才能执行试图函数，并且请求携带的参数也在request对象中，但是在flask 中，request 对象是一个全局对象，那么在多个请求过来时，flask是如何处理，才能在多线程条件下保证request对象携带参数是正确的？答案就在flask 的请求上下文管理中

flask 处理方案

入口还是在 app.run() 方法。

在 Flask 类中，可以发现重写的 __ call__ 方法。每当请求过来时，都会加括号执行app，因此都会自动执行__ call__方法。

继续往下，可以发现 wsgi_app 方法源码如下

继续往下，可以发现。request_context 实际上就是返回了 RequestContext 类的对象

回到 wsgi_app 方法中

push 源码

节约时间。下方直接 copy 参考博客截图。原文地址如下
_request_ctx_stack是LocalStack类的实例化对象：

LocalStack类中的__init__方法如下：

Local类的__init__方法如下：

get_ident是Local类所在文件中导入的一个方法名，该方法执行后会得到线程或协程ID，如下：
　　　

LocalStack类中的top是一个属性方法，源码如下：

下一步Local类中的__getattr__方法源码如下：

到此，分析得出top = _request_ctx_stack.top中的top为None。

接下来分析 **_request_ctx_stack.push(self)**做了什么？LocalStack类中的push方法源码如下：

Local类中的__setattr__方法源码如下：

因为rv.append(obj)，所以最后LocalStack对象，即_request_ctx_stack对象字典化后如下：

{'_local':{'__storage__':{9527:{stack:[ctx]}}, '__ident_func__':get_ident}}
# 说明：9527假设是获取到的线程或者协程号，ctx包含request对象和session对象。

到此，flask请求上文结束，也就是完成了将一个request和session对象存储到某个地方。

总结

1.  请求来时，flask 会把档次请求对象 request 放到 local 对象中，每个请求都是一个线程local对象实际管理的就是一个字典，里面以线程或者协程id为key，请求对象为value 值
2.  使用时，会根据 key 到 local 对象中取值，确保携带的值不会出错
3.  请求结束，flask 会把 该次 request 对象从local中移除
4.  g 对象和 session 也是采用上述相同处理。

补充

在阅读过程中发现，request对象，session和g对象都是同一个类 LocalProxy的对象，

LocalProxy类是个代理类， 重写了所有的魔法方法。来我们在使用时，request，session，g对象的属性打印出来的属性不一致。