https://docs.djangoproject.com/zh-hans/2.2/topics/http/middleware/
中间件工厂是一个可调用的程序，它接受 get_response 可调用并返回中间件。中间件是可调用的，它接受请求并返回响应，就像视图一样。
中间件可以被写成这样的函数：
def simple_middleware(get_response):
# One-time configuration and initialization.
def middleware(request):
# Code to be executed for each request before
# the view (and later middleware) are called.
response = get_response(request)
# Code to be executed for each request/response after
# the view is called.
return response
return middleware
或者它可以写成一个类，它的实例是可调用的，如下：
class SimpleMiddleware:
def __init__(self, get_response):
self.get_response = get_response
# One-time configuration and initialization.
def __call__(self, request):
# Code to be executed for each request before
# the view (and later middleware) are called.
response = self.get_response(request)
# Code to be executed for each request/response after
# the view is called.
return response
Django 提供的 get_response 响应可能是实际视图（如果这是最后列出的中间件），或者它可能是链中的下一个中间件。不需要知道或关心当前的中间件到底是什么，它只是代表了下一步的内容。
以上是一个轻微的简化——链中最后一个中间件调用的 get_response 可不是实际视图，而是处理程序的包装方法，它负责应用 view middleware，调用具有适当URL参数的视图，并应用 template-response 和 exception 中间件。
中间件可以放在 Python 路径上的任何地方。
__init__(get_response)
中间件工厂必须接受 get_response 参数。还可以初始化中间件的一些全局状态。记住两个注意事项：
Django仅用 get_response 参数初始化您的中间件，因此不能定义 __init__() ，因为需要其他参数。
与每次请求调用 __call__() 方法不同，当 Web 服务器启动时，__init__() 只被称为*一次*。
标记未使用的中间件
在启动时确定是否应该使用一个中间件有时是有用的。在这些情况下，您的中间件的 __init__() 方法可能会引发 MiddlewareNotUsed。Django 将从中间件进程中删除该中间件，并将调试消息记录到 django.request 日志：设置 DEBUG 为 True。
激活中间件
若要激活中间件组件，请将其添加到 Django 设置中的 MIDDLEWARE 列表中。
在 MIDDLEWARE 中，每个中间件组件由字符串表示：指向中间件工厂的类或函数名的完整 Python 路径。例如，这里创建的默认值是 django-admin startproject：
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 安装不需要任何中间件——如果您愿意的话，MIDDLEWARE 可以为空——但是强烈建议您至少使用 CommonMiddleware。
MIDDLEWARE 的顺序很重要，因为中间件会依赖其他中间件。例如：类 AuthenticationMiddleware 在会话中存储经过身份验证的用户；因此，它必须在 SessionMiddleware 后面运行 。中间件。Session中间件。请参阅 Middleware ordering ，用于一些关于 Django 中间件类排序的常见提示。
中间件顺序与分层¶
在请求阶段，在调用视图之前，Django 按照定义的顺序应用中间件 MIDDLEWARE，自顶向下。
你可以把它想象成一个洋葱：每个中间件类都是一个“层”，它覆盖了洋葱的核心。如果请求通过洋葱的所有层（每一个调用 get_response ）以将请求传递到下一层，一直到内核的视图，那么响应将在返回的过程中通过每个层（以相反的顺序）。
如果其中一层决定停止并返回响应而不调用get_response，那么该层(包括视图)中的洋葱层都不会看到请求或响应。响应将只通过请求传入的相同层返回。
其他中间件钩子¶
除前面说书的基础请求/响应中间件模式外，你可以给基于类的中间件添加三种其他特殊方法：
process_view()¶
process_view(request, view_func, view_args, view_kwargs)¶
request 是一个 HttpRequest 对象。view_func 是一个 Django 将要使用的 Python 函数。（这是一个真实的函数对象，不是函数的名称）；view_args 是一个用来传递给视图的位置参数列表，；view_kwargs 是一个用来传递给视图的关键字参数字典。view_args 和 view_kwargs 都不包含第一个视图参数 ( request )。
process_view() 只在 Django 调用视图前被调用。
它应该返回 None 或 HttpResponse 对象。如果它返回 None ，Django 将继续处理这个请求，执行任何其他的 process_view() ，然后执行相应的视图。如果它返回 HttpResponse 对象，Django 不会去影响调用相应的视图；它会将响应中间件应用到 HttpResponse 并返回结果。
注解
在视图运行前或在 process_view() 内访问中间件里的 request.POST 将阻止中间件之后运行的任何视图修改请求的上传处理程序 （modify the upload handlers for the request ），通常应该避免这样。
CsrfViewMiddleware 类可以被视为一个例外，因为它提供 csrf_exempt() 和 csrf_protect() 装饰器，它们允许视图完全控制 CSRF 验证在什么时候进行。
