我正在玩 Flask，努力了解會話如何工作的細節，我正在使用：Python 3.6.1燒瓶 0.12.2Flask 文檔清楚地說明（粗體是我的）：session 對象的工作方式與普通的 dict 非常相似，不同之處在于它跟蹤修改。這是一個代理。...關于代理的部分提到（再次，粗體是我的）：如果您需要訪問被代理的底層對象，您可以使用該 _get_current_object()方法session._get_current_object()因此，對于請求，底層對象 ( ) 必須保持不變，或者如本答案和評論所建議的那樣，一個線程。但是，它不會持續存在，也不會在請求內部，也不會線程。這是一個演示代碼：import threading from flask import ( Flask, session, ) app = Flask(__name__) app.secret_key = 'some random secret key' @app.route('/') def index(): print("session ID is: {}".format(id(session))) print("session._get_current_object() ID is: {}".format(id(session._get_current_object()))) print("threading.current_thread().ident is: {}".format(threading.current_thread().ident)) print('________________________________') return 'Check the console! ;-)'如果你將運行上面的 Flask 應用程序，并反復轉到will/返回的session._get_current_object()--id，偶爾會更改，而threading.current_thread().ident從不更改。這導致我提出以下問題：究竟返回的是什么session._get_current_object()？我知道它是一個對象底層session代理，但是這個底層對象綁定到什么（如果它不是請求而不是線程，如果有什么我希望它永遠不會改變，對于上面的簡單應用程序）？
2 回答
蝴蝶不菲
TA貢獻1810條經驗 獲得超4個贊
究竟返回的是
session._get_current_object()什么？
從技術上講，它是在名為 的實例session中最頂層元素的屬性中引用的對象。 該堆棧的最頂層元素是在中實例化的a，每個 HTTP 請求都會調用它。與本地堆棧之間的實現方法及其自身。該方法還負責為上下文請求新會話。LocalStack_request_ctx_stackRequestContextFlask.wsgi_appRequestContextpushpop_request_ctx_stackpush
這個會話是在session代理中可用的；RequestContext已初始化的請求可通過request代理獲得。這兩個代理只能在請求上下文中使用，即處理活動的 HTTP 請求。
我知道它是一個對象底層會話代理，但是這個底層對象綁定到什么（如果它不是請求而不是線程，如果有什么我希望它永遠不會改變，對于上面的簡單應用程序）？
如上所述，由session本地代理代理的請求上下文會話屬于RequestContext. 它隨著每個請求而變化。如上下文生命周期中所述，為每個請求創建一個新上下文，并且每次push執行時都會創建一個新會話。
在連續請求之間保持相同的 idsession._get_current_object()可能是由于新會話對象創建在與前一個請求中的舊會話對象所占用的內存地址相同的內存地址中。
另請參閱： Flask 文檔的上下文如何工作部分。
慕容森
TA貢獻1853條經驗 獲得超18個贊
這是修改后的代碼片段，以說明shmee的答案
import threading
from flask import (
Flask,
session,
request
)
app = Flask(__name__)
app.secret_key = 'some random secret key'
@app.route('/')
def index():
print(">>> session <<<")
session_id = id(session)
session_object_id = id(session._get_current_object())
print("ID: {}".format(session_id),
"Same as previous: {}".format(session.get('prev_sess_id', '') == session_id))
print("_get_current_object() ID: {}".format(session_object_id),
"Same as previous: {}".format(session.get('prev_sess_obj_id', '') == session_object_id))
session['prev_sess_id'] = session_id
session['prev_sess_obj_id'] = session_object_id
print("\n>>> request <<<")
request_id = id(request)
request_object_id = id(request._get_current_object())
print("request ID is: {}".format(request_id),
"Same as previous: {}".format(session.get('prev_request_id', '') == request_id))
print("request._get_current_object() ID is: {}".format(id(request._get_current_object())),
"Same as previous: {}".format(session.get('prev_request_obj_id', '') == request_object_id))
session['prev_request_id'] = request_id
session['prev_request_obj_id'] = request_object_id
print("\n>>> thread <<<")
thread_id = threading.current_thread().ident
print("threading.current_thread().ident is: {}".format(threading.current_thread().ident),
"Same as previous: {}".format(session.get('prev_thread', '') == thread_id))
session['prev_thread'] = thread_id
print('-' * 100)
return 'Check the console! ;-)'
實際上，唯一留下的模糊之處是為什么有時 session._get_current_object()在連續請求之間保持不變。正如shmee所建議的（粗體是我的），它是：
可能是因為新會話對象是在與前一個請求中的舊會話對象占用的內存地址相同的內存地址中創建的。
添加回答
舉報
0/150
提交
取消