flask 本地執行緒 請求上下文補充

context（上下文）是flask裡面非常好的設計，使用flask需要非常理解應用上下文和請求上下文這兩個概念

本地執行緒

本地執行緒的實現原理就是：在threading.current_thread().__dict__裡新增乙個包含物件mydata的id值的key，來儲存不同的執行緒狀態

werkzeug自己實現了自己的本地執行緒。werkzeug.local.local和threading.local的區別如下：

werkzeug使用了自定義的__storage__來儲存不同執行緒下的狀態
werkzeug提供了釋放本地執行緒的release_local方法
werkzeug使用了兩種方法來通過get_ident函式獲取執行緒的識別符號*（greenlet，系統執行緒，預設使用系統的，如果安裝了greenlet則使用她）

localstack：基於werkzeug.local.local實現的棧結構，可以將物件推入，彈出，也可以快速拿到棧頂物件

localproxy：作用和名字一樣，是標準的**模式。構造次結構時接收乙個可以呼叫的引數（一般是函式），這個函式執行後就是通過localstack例項化的棧的棧頂物件。
基於localproxy物件的操作實力上都會**到這個棧頂物件（也就是乙個threadlocal上邊）

from flask import

flask, request)'
/')def
***():
name = request.args.get("
name
")

flask.request就是乙個獲取名為_request_ctx_stack的棧頂物件的localproxy例項：

from functools import

partial
from werkzeug.local import
localproxy
def_lookup_req_object(name):
top =_request_ctx_stack.top
if top is
none:
raise runtimeerror("
***xx")
return getattr(top, name)

1：使用者訪問產生請求

2：在發生請求的過程中向_reqeust_ctx_stack推入這個請求的上下文物件，他會變成棧頂，request就會成為這個請求上下文，也就包含了這次請求的相關資訊和資料
3：在檢視函式中使用request就可以使用request.args.get('
name
')了

設想不使用localstack和localproxy的話，要想讓檢視函式訪問的請求物件，就只能將其作為引數，一步步的傳入檢視函式中。這樣做的缺點是會讓每個檢視函式都增加乙個request引數，

而flask卻巧妙的使用了上下文把某些物件設定成全域性訪問，每個執行緒看到的上下文物件卻是不同的，這樣就巧妙的解決了這個問題

應用上下文的典型場景是快取一些在發生請求之前要使用到的資源，比如生成資料庫鏈結和快取一些物件；請求上下文發生在http請求的開始，wsgi server呼叫flask.__call__()之後。

應用上下文並不是應用啟動之後生成的唯一上下文

flask之請求上下文

第一階段 將ctx request,session 放到local物件上 第二階段 檢視函式匯入 request session request.method localproxy物件.method,執行getattr方法，getattr self.get current object name s...

flask請求鉤子 請求上下文

from flask import flask from flask import redirect,url for,abort 在第一次請求之前呼叫，可以在當前的方法中初始化操作 def before first request print before first request 在每一次請求之...

Flask 應用和請求上下文

from flask import request defindex user request.headers.get user agent return you browserid format user 標題flask應用上下文和請求上下文 變數名上下文說明 應用上下文 當前應用的應用例項 g應...