flask上下文全局變量，程序上下文、請求上下文、上下文鉤子 --

Flask上下文

 

Flask中有兩種上下文，程序上下文（application context）和請求上下文（request context）

當客戶端發來請求時，請求上下文就登場了。請求上下文裏包含了請求的各類信息，好比請求的URL，請求的HTTP方法等。

 

上下文全局變量

視圖函數須要上下文信息，flask將請求報文封裝在request對象中，可是在視圖函數中，並無把它傳進視圖函數，而是直接從Flask導入一個全局的request對象，而後在視圖函數裏直接調用request的屬性獲取數據。爲何在處理請求時，視圖函數裏的request會自動包含對應請求的數據呢？由於flask在每一個請求產生後自動激活當前請求的上下文，激活請求上下文後，request被臨時設爲全局可訪問。當每一個請求結束後，flask就銷燬對應的請求上下文。

 

咱們在前面說request是全局對象，但這裏的全局並非實際意義上的全局。咱們把這些變量理解爲動態的全局變量。

 

在多線程服務中，在同一時間可能會有多個請求在處理。假設有三個客戶端同時向服務器發送請求，這時每一個請求都有各自不一樣的請求報文，因此請求對象必然是不一樣的。

所以，請求對象只在各自的線程內是全局的。flask經過本地線程（thread local）技術將請求對象在特定的線程和請求中全局可訪問。

 

爲了方便獲取這兩種上下文環境那種存儲的信息，flask提供了四個上下文全局變量

 

在不一樣的視圖函數中，request對象都表示和視圖函數對應的請求，就是當前請求（current request）。程序會有多個程序實例的狀況，爲了能獲取對應的程序實例，而不是固定的某一個程序實例，咱們就須要使用current_app變量。

 

g存儲在程序上下文中，而程序上下文會隨着每個請求的進入而激活，隨着每個請求的處理完畢而銷燬，因此每次請求都會重設這個g值。

咱們一般會使用它結合鉤子來保存每一個請求處理前所須要的全局變量。

 

當請求進入時，flask會自動激活請求上下文，這時可使用request和session變量。當請求上下文被激活時，程序上下文也被自動激活。

 

除了上面四個上下文變量，依賴上下文的還有url_for()和jsonify()函數，因此只能在視圖函數中使用它們。其中jsonify()函數內部調用中使用了current_app變量，url_for()則須要依賴請求上下文才能夠正常運行。

 

程序上下文能夠用with語句執行操做

 

程序上下文也能夠顯示地使用push()方法推送（激活），在執行完操做後，用pop()方法銷燬上下文

 

請求上下文能夠經過test_request_context()方法臨時建立

 

一樣的，這裏也可使用push()和pop()方法顯示地激活和銷燬上下文

 

上下文鉤子（回調函數）

flask爲上下文提供了一個teardown_appcontext鉤子，使用它註冊的毀掉函數會在程序上下文被銷燬時調用，一般也在請求上下文被銷燬時調用，好比你須要在每一個請求處理結束後銷燬數據庫鏈接：

 

@app.teardown_appcontext

def teardown_db(exception):

    db.close()

 

app.reardown_appcontext裝飾器註冊的回調函數須要接收異常對象做爲參數，當請求被正常處理時這個參數將是None，這個函數的返回值將被忽略