一、中间件

　　在django的settings.py文件下，有一个变量为MIDDLEWARE，里面放的就是中间件。

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]






上面就是Django自带的7个中间件，我们想看中间件长什么样子，只需要复制中间件，用from引入，点进去看就可以了。
比如看第二个中间件：from django.middleware.sessions.middleware import SessionMiddleware，看到的结果如下：

class SessionMiddleware(MiddlewareMixin):
    def __init__(self, get_response=None):
        self.get_response = get_response
        engine = import_module(settings.SESSION_ENGINE)
        self.SessionStore = engine.SessionStore

    def process_request(self, request):
        session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME)
        request.session = self.SessionStore(session_key)

    def process_response(self, request, response):
　　　　　。。。。。。
我把process_response()方法下的东西省略了。但我们可以清楚的看出它就是一个继承于MiddlewareMixin的类。

　　所谓的中间件，就是存在于socket和视图函数中间的一种过滤器。浏览器客户端通过socket发送请求来，要经过一层层中间件的process_request（）方法，在进入视图，视图函数执行完毕后，又要经过一层层中间件的process_response()方法，然后再通过socket发送给浏览器客户端。Django服务器端的socket是由wsgiref模块封装而成的，它还帮我们把原生的数据解析成了request对象，从而在Django服务器端才可以用request对象去拿值。

　　中间件有四个方法，分别是：

1，process_request(self,request)
2，process_response(self, request, response)
3，process_view(self, request, callback, callback_args, callback_kwargs)
4，process_exception(self, request, exception)

　　现在我们一个一个的来分析每个方法的运用及效果，四个方法讲完了，中间件就学完了。

　　二、process_request()，process_response()

　　上面我们说了，浏览器发送请求过来，会经过一层层的process_request，具体来说，会从最上面的中间件到最下面的中间件。执行完视图函数之后，会从从下往上执行每个中间件的process_response()，之后再发送给浏览器。

　　通常情况下，process_request()是不会写return的，一旦某个中间件的process_request()写了return，那后面的中间件的process_request()就不会执行了，也不会到视图函数了，直接从自己的process_response()依次往上返回。

　　通常情况下，process_response()都要写上return response。一旦有一个中间件的process_response()没有写return response，那么数据走到这一个中间件时，数据就会丢失，后面要执行的中间件的process_response()都会没有数据。

　　三、process_views()

　　上面的第二点的执行流程是基于只有request和response的情况下的，如果加上了process_views()。首先还是先走每个中间件的request，然后走到urls.py文件，但现在不会马上去执行视图，而是先要从上往下走每个中间件的process_views(),走完之后再走视图函数，再走每个中间件的response。

　　第一步是process_request,第二步是process_views,第三步是执行视图函数，第四步是process_response

　　通常情况下，process_views 也不要加return Httpresponse（’fff’），一旦加上了，从这个中间件以下的中间件的process_views就不会执行，视图函数也不会执行。直接跳到最下面中间件的response开始返回。

　　第一步是process_request,第二步是走部分的process_views,第三步是process_response

　　process_views()方法还可以写上回调视图函数，它会把对应的视图函数给执行了，然后返回

def process_view(self,request,callback,callback_args,callback_kwargs):    response=callback(request,*callback_args,**callback_kwargs)     
　　　#callback就是在经过urls.py时对应的视图函数，现在直接在process_views（）直接回调视图函数，并且执行
     return response
这种情况下，会在执行这个中间件的process_views，把对应的视图函数也一起执行了，然后就直接到最下面中间件从下往上执行response，返回

　　第一步是prosee_request，第二步是走部分的process_views，第三步是执行process_views里的回调视图函数，第四步是process_response

　　四、process_exception()

　　上面的执行流程是基于没有process_exception()情况下的，加上process_exception(),在执行完视图函数之后，后从下往上执行中间件的process_exception(),然后在从下往上执行中间件的response，然后返回。process_exception()的作用是捕获视图函数的错误。

　　第一步是process_request,第二步process_views,第三步执行视图函数，第四步process_exception,第五步是process_response.