1. 中间件(middleware)
Django中的中间件主要实现一些附加功能，在request被用户handler处理前，以及用户handler处理后生存的response进行处理。因此大部分中间件的主要功能是实现了process_request或者process_response之一，当然也可以两者都实现，意味着该中间件涉及到处理的request和response的处理。
1.1 类视图
在中间件的类关系中，基本类是MiddlewareMixin，其他所有的中间件类都继承自该类，该类仅有一个成员变量get_response，该变量在连接各个中间件起着非常重要的作用。该类有两个成员函数：__init__和__call__，前者用于实现初始化，后者执行主要的功能。
def __call__(self, request):
response = None
if hasattr(self, 'process_request'):
response = self.process_request(request)
if not response:
response = self.get_response(request)
if hasattr(self, 'process_response'):
response = self.process_response(request, response)
return response
其中process_request和process_response自不必多言，中间件需要实现的主要功能，通过hasattr()调用，判断当前中间件是否具有process_request和process_response，有则调用。
不同功能的中间件，根据要完成的功能，可以扩展自己的成员变量和成员函数，通常，自定义的成员函数被process_request和process_response调用，即这些自定义的成员函数通常不对外开放。
其中，__init__成员函数有入参函数之一: get_response,这在后续的加载中间件时很重要好。
下图是中间件SecurityMiddleware类的类视图关系图，其他中间件的视图关系类似。
1.2 中间件初始化
在工程的配置文件(Project/Project/setting.py)中指定要使用的中间件，注意各插件在序列中的顺序，这决定了当请求到来时，各个中间件的执行顺序，排在最前面的中间件得到最先执行，最后的中间件最后执行。其表现通常如下所示:
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',
]
下面来看，中间件是如何被加载和初始化的。class BaseHandler(object):中定义了load_middleware接口，具体细节如下：
handler = convert_exception_to_response(self._get_response) /*handler[0]*/
for middleware_path in reversed(settings.MIDDLEWARE):
middleware =
import_string(middleware_path)
mw_instance = middleware(handler)
handler = convert_exception_to_response(mw_instance) /*handler[i]*/
self._middleware_chain = handler /*handler[end]*/
在上述例程中，开始遍历所有中间件之前，handler(即handler[0])赋值给调用实体的_get_response成员函数。 (比如class WSGIHandler(base.BaseHandler)，WSGIHandler. load_middleware()调用之后，handler[0] = WSGIHandler._get_response = BaseHandler._get_response())。遍历所有中间件过程中，加载并初始化(middleware()调用对应着__init__成员函数)中间件，因此中间件的get_response赋值为handler[i]，注意middleware()返回一个中间件类实体，接着调用调用handler = convert_exception_to_response (mw_instance)，convert_exception_to_response只是对输入函数进行了容错封装，在分析逻辑时，可以简单看成输入函数本身，因此，可以看成handler = mw_instance(request)，对于一个类实体调用即调用__call__成员函数，从目前来看，大部分的中间件并没有重载该成员函数，因此是直接调用基类的成员函数，即: MiddlewareMixin. __call__(self)。因此handler[i] = MiddlewareMixin. __call__(self)。注意该函数有一个self输入参数，各个中间件在调用时，传入该中间件对应的self实体，这样self.process_request, self.process_response的调用就分别对应着不同中间夹的处理函数。load_middleware()调用之后，各个中间件通过get_response链接起来，这样一个request请求到来时，可以顺序通过各个中间件依次进行处理，如下图所示：
在调用的最后，将self._middleware_chain = handler[end]，类似于将中间件链表的链表头保存起来，下次处理时，从该链表头开始进行遍历处理。
1.3 中间件使用
各个中间件的调用顺序如下递归图所示：
在类视图一节中对__call__基类成员函数进行过介绍，该函数主要有先后执行的三个函数构成:process_request()、get_response()、process_response()，而get_response()通常指向下一个中间件的__call__成员函数(中间件链表的最后一个中间件除外，其get_response()指向handler[0])，由于各个中间件的get_response()这一特性(绝大部分指向基类__call__成员函数)，使得中间件链表处理有点类似递归调用的感觉。A,B,A1,B1,A2,B2,C2,C1,C，这一递归调用顺序，决定了各个中间件处理的一些特点：
1、最先进行流程处理的中间件，其process_request()(如果存在的话)最先被执行，但是其process_response()(如果存在的话)却最后得到处理。
2、最后进行流程处理的中间件，其process_request()(如果存在的话)最后被执行，但是其process_response()(如果存在的话)紧接着得到处理。
3、在中间件处理流程中，如果出现某个中间件的process_request()返回了response，这种情况通常是处理过程中出现了异常情况，该中间件后续的中间件不再参与处理，直接调用该中间件的process_response()(如果存在的话)，或者直接返回。