科技 · 實用指南
Python ContextVar 在執行緒集區中遺失？釐清上下文傳播與修改回傳
區分非同步工作、to_thread、執行緒集區與行程：每次提交執行緒工作都複製上下文，並明確回傳修改結果。
ContextVar 跨越不同並行執行邊界時，行為並不相同。asyncio Task 保留工作的上下文，asyncio.to_thread 會將目前的 Context 複製到工作執行緒；直接提交給 ThreadPoolExecutor 或呼叫 loop.run_in_executor 時，若框架沒有代為處理，就必須明確複製。
將上下文傳入工作執行緒，與把執行緒內的修改帶回呼叫端，是兩件事。每次提交都擷取一份新副本，在副本中執行一次呼叫；要帶回的修改應作為結果回傳。跨行程時另行傳遞資料，並以兩個並行請求驗證隔離。
1. 先確認呼叫跨越了什麼邊界
記錄呼叫是在 asyncio Task 內執行、使用 asyncio.to_thread、呼叫 loop.run_in_executor、直接提交給 ThreadPoolExecutor，還是進入另一個行程。不要只憑函式名稱或框架名稱推斷行為。
在邊界兩側記錄不含敏感資訊的請求標記。標記缺失表示傳播未成功；出現上一個請求的值表示工作執行緒殘留了狀態；只有明確複製後才出現預期值，則表示傳播由包裝層負責。
2. 每次提交執行緒工作時複製上下文
直接提交執行緒工作時，在發起請求的上下文中執行 ctx=contextvars.copy_context()，再提交 ctx.run、目標函式及其引數。每次提交都要擷取副本，不要只在建立長期使用的執行緒集區時複製一次。
不要讓兩個工作執行緒同時進入同一個 Context：重複進入已在執行中的上下文會觸發 RuntimeError。每次呼叫使用新副本，也能確保擷取的是目前請求的狀態，而非集區啟動時的狀態。
3. 分開處理傳入上下文與回傳修改
asyncio.to_thread 明確提供向工作執行緒傳播上下文的行為；框架輔助函式也可能在 run_in_executor 外做相同包裝。但這不代表工作執行緒中的 ContextVar 賦值會自動寫回等待它的 Task。
若工作執行緒算出新的租戶、追蹤跨度或授權結果，應以一般資料回傳，讓呼叫端決定是否設定或重設自己的 ContextVar。暫時覆寫呼叫端狀態時，保留 set() 回傳的 token，並在 try/finally 中呼叫 reset() 還原。
4. 分別處理執行緒與行程
CPython 討論未替 run_in_executor 採用統一的自動傳播規則，原因之一是它也能使用 ProcessPoolExecutor，而 Context 物件無法透過 pickle 序列化。不要把僅適用於執行緒的包裝方式套用到行程邊界。
跨行程時，明確傳入小型、可序列化的請求上下文，在工作行程中驗證，並明確回傳結果。憑證與大型可變物件應遵守行程介面的安全及所有權規則，不能將它們視為隨處可讀取的 ContextVar 狀態。
5. 用實際呼叫路徑驗證請求隔離
透過正式環境使用的輔助函式，發起標記分別為 A、B 的兩個重疊呼叫，並以同步屏障確保兩個工作執行緒同時運作。確認 A 只看到 A、B 只看到 B，未包裝的對照呼叫則取得文件約定的預設值。
讓兩個工作執行緒各自設定不同的區域值並回傳。await 或 Future.result() 之後，確認呼叫端仍保留原標記，直到它主動修改或重設。錯誤處理與關閉路徑也應重複檢查，避免執行緒集區殘留上一個請求的值。
