一、中间件
在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.
原文地址：https://www.cnblogs.com/12345huangchun/p/10251958.html