异步函数中直接读写全局变量会导致协程间上下文污染，引发用户ID错乱、权限校验错误等问题；threading.local在asyncio中失效，因协程共享同一线程；应使用ContextVar配合set/get/reset确保上下文隔离。
异步函数里直接读写全局变量会出什么问题
不安全，而且非常容易踩坑。Python 的 asyncio 在单线程内调度多个协程，它们共享同一个全局命名空间，但执行是交错的。如果你在 async def 里修改一个模块级变量（比如 current_user_id = None），不同请求协程会互相覆盖——A 请求刚设了 current_user_id = 101，还没用就切到 B 请求把它改成 202，A 回来再读就错了。
典型现象包括：日志里用户 ID 错乱、权限校验拿错上下文、数据库事务关联错误 session ID。这不是竞态条件（没多线程锁问题），而是逻辑上下文被污染。
为什么不能用 threading.local 替代 ContextVar
threading.local 在 async 场景下完全失效。它绑定的是 OS 线程，而 asyncio 协程都在主线程里切换，所有协程共享同一个 threading.local 实例。你设了 local.user_id = 101，下一个协程读出来还是 101，根本不会隔离。
- 协程切换不触发
threading.local新实例创建 - 即使开了多线程运行 event loop（如
ThreadPoolExecutor），也只在子线程里生效，主线程协程仍共享 - Pytest 或某些测试框架里 mock 全局状态时，更容易暴露这个问题
ContextVar 正确用法：声明 + set + get 缺一不可
ContextVar 不是“自动注入”的魔法变量，必须显式调用 set() 和 get()，且 set() 返回的 token 要配合 reset()（尤其在异常路径中）。
立即学习“Python免费学习笔记（深入）”；
from contextvars import ContextVar
user_id_var = ContextVar('user_id', default=None)
async def handle_request():
# 正确：绑定当前协程上下文
token = user_id_var.set(101)
try:
await do_something()
finally:
user_id_var.reset(token) # 必须重置，否则泄漏到其他协程
def get_current_user_id():
return user_id_var.get() # 安全读取，自动找当前协程的值
- 不调用
set()就直接get()，返回的是default值，容易掩盖逻辑遗漏 - 忘记
reset()会导致该值“泄漏”到后续协程（尤其在中间件、装饰器里） - 不能在
set()后跨协程传递 token；token 只在当前协程有效
FastAPI/Starlette 中怎么自然集成 ContextVar
Web 框架本身不自动管理 ContextVar，需要在请求生命周期起始处 set()，结束时 reset()。FastAPI 推荐用依赖项（Dependency）封装，Starlette 则常用 middleware。
# FastAPI 依赖示例
from fastapi import Depends, Request
from contextvars import ContextVar
user_id_var = ContextVar('user_id', default=None)
async def set_user_context(request: Request):
user_id_var.set(int(request.headers.get('X-User-ID', '0')))
yield
user_id_var.reset(user_id_var.get()) # 注意：这里 reset 需要原始 token，实际应存 token
# 更稳妥写法是在依赖里保存 token 并 yield
关键点：middleware 或 dependency 必须确保 set() 和 reset() 成对出现，且不能依赖 try/finally 在异步生成器里 —— 异常可能中断 yield，得用 contextlib.AsyncExitStack 或框架提供的 cleanup 钩子。很多线上 bug 就出在 reset 被跳过。
真正难的不是写几行 ContextVar，而是把整个调用链（包括日志、DB 连接、缓存 key 生成）都统一用同一套上下文变量串起来，漏掉一环就前功尽弃。
