場景介紹
很多些時候，在做 flask 程序的時候，我們需要用到一些全局變量，比如用戶的登錄信息等
blog 中的搜索功能，需要在不同的頁面都顯示搜索，最笨的方法是每個頁面都實現一個搜索功能，但是這樣太重復，太繁瑣，違反了“簡單”原則。一個好的程序員會把重復的事情都模塊化，簡單化。
我們可以每個 url 都用到了同意同一個搜索功能。這需要我們用到一個全局的搜索功能。
全攬：
- current_app # 當前激活程序的程序實例
- g # 處理請求時用作臨時存儲的對象。每次請求會重設這個變量
- request # 請求對象，封裝了客戶端發出的http請求中的內容
- session # 用戶會話，用於存儲請求之間需要‘記住‘的值的詞典
圖解
盜圖了，改天我自己畫一張詳細的
一. g
1. 基本了解
g作為flask程序全局的一個臨時變量,充當者中間媒介的作用,我們可以通過它傳遞一些數據
從0.10開始g兌現就不是在request的級別，而是在應用上下文的級別。flask從0.10開始g是和app綁定在一起了。
但不同請求的AppContext是不同的，所以g還是不同。也就是說你不能再一個視圖中設置g.name，然后再另一個視圖中使用g.name，會提示AttributeError。
-- 注意：大多數代碼示例基於login函數，但是在實際項目中，給g賦值應基於登錄校驗的裝飾器函數，在不同請求中，g 並不是同一個 g；換言之，當前請求完全結束時，當前的 g 也就銷毀了 --
請求鈎子： 說到g變量，就不得不說鈎子函數
- before_first_request:注冊一個函數，在處理第一個請求之前運行;
- before_request:注冊一個函數，在每次請求之前運行;
- after_request:注冊一個函數，如果沒有未處理的異常拋出，在每次請求之后運行；
- teardown_request:注冊一個函數，即使有未處理的異常拋出，也在每次請求之后運行
在請求鈎子函數和視圖函數之間共享數據一般使用上下文全局變量g。例如，before_request處理程序可以從數據庫中加載已登錄用戶，並將其保存到g.user中。隨后調用視圖函數時，視圖函數再使用g.user獲取用戶。
2. 實現原理
問題: 多線程的環境下，是如何保證request沒有混亂的?
參考： https://blog.csdn.net/yueguanghaidao/article/details/39533841
二. current_app
三. request
四. session
參考來自： https://blog.csdn.net/hyman_c/article/details/53512109