本文講述的內容基于 Django 1.11

摘要

Django 中的中間件（middleware），是一個鑲嵌到Django的request/response處理機制中的一個hooks框架，是一個修改django全局輸入輸出的一個底層插件系統。讓我們可以自定義想要的一些功能來處理用戶的請求。

在Django中，中間件其實就是一個類，在類中包含一組特定的功能，在請求到來或者結束時，Django會根據我們定義的中間件規則執行中間件中對應的方法，一個 Django 項目默認激活的中間件在我們項目中的配置中可以看到是這個樣子的：

settings.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',]

MIDDLEWARE這里列表中的每一個元素，其實就是一個個單獨的中間件，舉例來說：django.middleware.csrf.CsrfViewMiddleware這個中間件，作用就是在我們的 form 表單提交請求的時候，提交的時候必須要帶上csrf_token，否則就不會正確提交。

中間件使用也需要講究順序，下一層依賴上一層的封裝，例如，我們的AuthenticationMiddleware是一個認證中間件，在session 中保存認證用戶的信息，但是他必須依賴于SessionMiddleware才可以被正確使用，所以他也必須在SessionMiddleware之后。但是具體的順序問題可以參考這里

中間件結構

中間件類中需要包含以下處理方法：

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

執行過程

以我們的項目中默認中間件為例子，具體的流程如下所示：

中間件執行前提

中間件要按照一定的順序一層一層的執行下去，需要按照標準返回特定的內容：

• 如果為 None，則按照順序繼續向下執行
• 如果為 HttpResonse 對象，則直接將這個對象返回給用戶

此處有一個版本前后的區別，請大家注意區分：

在 Django1.10之后， 當某個中間件，例如CsrfViewMiddleware請求process_request沒有返回 None 后，這個請求會交給CsrfViewMiddleware的process_response來返回，即返回給相同一層的中間件來返回:

在 Django1.10之前的版本，會返回到最底層的中間件來返回:

中間件方法：

1、process_request(self, request)

其中request參數就是我們的HttpRequest對象，process_request 會在每個request在被決定使用哪個view之前調用，它會返回None或HttpResponse對象

2、process_view(self, request, callback, callback_args, callback_kwargs)

其中request參數就是的HttpRequest對象，callback 就是請求被決定使用的 view 函數，書具體的函數名，不是字符串類型。callback_args和callback_kwargs是 view 函數需要接受的參數，它會返回None或HttpResponse對象

3、process_template_response(self, request, response)

其中request 是 HttpRequest 對象， response 是一個由Django view或者中間件返回的TemplateResponse 對象,process_template_response()在 view 使用 render 渲染一個模版對象完成之后被調用，它必須返回一個render 方法執行后的response對象。

4、process_exception(self, request, exception)

其中request參數就是的HttpRequest對象，exception是view函數中raise的Exception對象，當 view 函數 raise 一個 exception 的時候調用process_exception，它會返回None或HttpResponse對象

5、process_response(self, request, response)

其中request是 HttpRequest 對象，response 是一個django view或者中間件返回的 HttpResponse 或者StreamingHttpResponse對象，process_response會在所有響應到達瀏覽器之前被調用

中間件的詳細執行流程

由于process_template_response在特定的 rander 渲染中才會被調用，所以過程中不添加該方法

自建中間件與執行過程測試

為了更加清晰的展示中間件的執行過程與如何自定義一個中間件，我們模擬一個簡單的用戶請求和中間件執行過程：

自定義中間件

from django.utils.deprecation import MiddlewareMixinclass MyMiddleware_1(MiddlewareMixin): def process_request(self, request):  print("自定義 process_request 1")  return None def process_response(self, request, response):  print("自定義 process_response 1")  return response def process_view(self, request, callback, callback_args, callback_kwargs):  print("自定義 process_view 1")  return None def process_exception(self, request, exception):  print("自定義 process_exception 1")class MyMiddleware_2(MiddlewareMixin): def process_request(self, request):  print("自定義 process_request 2")  return None def process_response(self, request, response):  print("自定義 process_response 2")  return response def process_view(self, request, callback, callback_args, callback_kwargs):  print("自定義 process_view 2")  return None def process_exception(self, request, exception):  print("自定義 process_exception 2")

引入

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', 'app01.middle_by_me.MyMiddleware_1', # 第一個自定義 middleware 'app01.middle_by_me.MyMiddleware_2' # 第二個自定義 middleware]

輸出結果

自定義中間件應用場景

應用場景這個問題其實不是很好去固定，因為大家在實際使用過程中的需求都不盡相同，所以我簡單的舉個我可以想到的例子吧。

在不修改業務邏輯源代碼的情況下，我可以使用中間件來對用戶的訪問進行一定的篩選過濾，或者訪問控制。還有能想到的更加牛逼的操作是當源站的 CDN，請求穿透源站，middleware 判斷請求的內容是否在緩存中，如果在緩存直接返回，而可以不經過業務后端邏輯，是不是很騷~

是不是很像一個所有視圖函數的裝飾器~~

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對VEVB武林網的支持。