Django系列 1：请求的生命周期
进入本文之前，首先请大家先看该篇博客，对你开始本文的理解有一定的帮助：Django启动源码分析。
一个请求request 经过浏览器， nginx转发，再到我们的应用服务器，这一过程我们暂且先跳过去，因为我们要研究的是一个请求request进入到应用服务器后， 如何匹配到视图类的(CBV)的，进入视图函数前干了什么， 出了视图函数干了什么，进入之前与出去之后都经过哪些中间件，这些是我们着重要研究的地方。
1：任何一个应用 application,他必须是可调用的(callable), 应为这是request的入口。源码位置在Django中的位置如下所示：
2：所有的request都会进入run方法：
进入run方法以后， 就会获取应用的application：
3：前面说过django中的application是一个可调用对象，那么application对应的类就是：django.contrib.staticfiles.handlers:StaticFilesHandler 实例
最后调用父类的的方法：django.core.handlers.wsgi:WSGIHandler，至此我们已经知道所有的request在django框架中的入口处。
好了， 现在我们已经知道每个请求的入口是WSGIHandler.__call__函数， name在这个函数最重要的就是这句代码 response =self.get_response(request)
那我们现在看看这句代码的背后都干了什么，重点在这句：self._middleware_chain(request)，它在项目启动后会将所有的中间件形成一个链，在链的最开始就是配置中MIDDLEWARE第一个中间件。
在load_middleware方法中，get_response最初是self._get_response方法（即：最初的handler就是get_response），通过循环每次handler改变， 第一次循环后handler就是MIDDLEWARE最后一个中间件的实例，一直到循环结束，那么handler就是第一个中间件的是实例；
当代码执行到：
self._middleware_chain(request)
当所有的中间件都执行完毕后，最后执行WSGIHandler的_get_response方法(如下图)， 该方法包括了，请求解析（找到正确的视图类），视图函数中间件，从wrapped_callback分派执行请求方法(get()、post()、........)，template中间件、exception中间件，最后又会执行所有中间件的process_response方法
所以一个请求到达应用服务器后的流程就是：
（1）：request 找到应用服务器 __call__(self, environ, start_response) 方法，并执行 response = self.get_response(request) 方法。
（2）：request 进入 self.get_response(request) 方法后，最重要的就是执行了该句代 码：response = self._middleware_chain(request)
（3）：中间件链 self._middleware_chain(request) 具体干了这么几件事：
（a）: 顺序执行中间件实例的 process_request 方法，如果该方法有返回 值 response 实例， 那么不会执行后续的中间件， 而是逆序执行中间件 的 process_response 方法，最后返回服务器直至浏览器
（b）: 当所有的 process_request 方法执行完毕后，执 行 WSGIHandler._get_response(self, request) 方法，根据请求的path解 析到正确的视图函数或视图类(即该方法的 callback或 wrapped_callback)
（c）: 执行所有的模板中间件
（b）: 执行所有的异常中间件
（d）: 最后逆序执行中间件实例的 process_response 方法，改方法必须返回 一个 response 实例 , 最后相应返回给wsgi或uwsgi 这样发服务器，由他 们返回浏览器等前端
那么整个请求的过程就是在这些过程中完成的，django框架的核心就是围绕这些流程逐步拓展，请求解析、模板与响应、异常处理等等。
最后补充一张图，关于请求穿过中间件的顺序:
