Django4.0 中间件-升级Django1.10之前的中间件

class django.utils.deprecation.MiddlewareMixin

Django 提供了 ​django.utils.deprecation.MiddlewareMixin​ 来方便创建同时兼容 ​MIDDLEWARE ​和旧的 ​MIDDLEWARE_CLASSES ​的中间件类，并支持同步和异步请求。Django 所包含的所有中间件类都兼容这两种配置。

​mixin ​提供了一个 ​__init__() ​方法，它需要一个 ​get_response ​参数，并将其存储在 ​self.get_response​ 中。

​__call__()​ 方法：

1. 调用 ​self.process_request(request)​ （如果被定义过）。
2. 调用 ​self.get_response(request)​ 来从后续的中间件和视图得到响应。
3. 调用 ​self.process_response(request, response)​ （如果被定义过）。
4. 返回响应。

如果和 ​MIDDLEWARE_CLASSES ​一起使用，​__call__() ​方法将永远不会被使用；Django 会直接调用 ​process_request()​ 和 ​process_response() ​。
在大多数情况下，从这个 ​Mixin ​中继承就足以使一个旧式中间件与新系统兼容，并具有足够的向后兼容性。新的短路语义对现有中间件无害甚至有益。在少数情况下，中间件类可能需要一些改变来适应新的语义。
​MIDDLEWARE ​和 ​MIDDLEWARE_CLASSES ​在使用上有些行为差异：

1. ​MIDDLEWARE_CLASSES ​下，每个中间件将始终调用它的 ​process_response ​方法，即使早期的中间件通过从其 ​process_response ​方法返回响应而短路。​MIDDLEWARE ​下，中间件行为更像洋葱：响应在输出时经过的层与在输入时看到请求的层相同。如果一个中间件短路，只有那个中间件和之前的中间件可以看到响应。
2. 在 ​MIDDLEWARE_CLASSES ​下，​process_exception ​应用于中间件 ​process_request ​方法引发的异常。在 ​MIDDLEWARE ​下，​process_exception ​只应用于视图引发的异常（或者从 ​TemplateResponse ​的 ​render ​方法引发的异常）。中间件引发的异常被转换为合适的 HTTP 响应，然后传递到下一个中间件。
3. ​MIDDLEWARE_CLASSES ​下，如果 ​process_response ​方法引发了异常，所有更早之前的中间件的 ​process_response ​方法会被跳过，并一直返回 ​500 Internal Server Error​ 的 HTTP 响应（即使引发的异常是例如 Http404 ）。在 ​MIDDLEWARE ​，一个中间件引发的异常将立刻被转换为合适的 HTTP 响应，然后下一个中间件将看到响应。中间件不会因为中间件引发异常而被跳过。