threading.local在协程中失效是因为它绑定操作系统线程而非协程，而asyncio通常单线程运行多协程，导致所有协程共享同一local实例；应改用contextvars实现协程安全的上下文隔离。
为什么 threading.local 在协程里会失效
因为 threading.local 绑定的是操作系统线程，不是协程。asyncio 事件循环通常只用一个线程跑成百上千个协程，所有协程共享同一个 threading.local 实例——变量一改全改，根本分不清谁是谁。
典型现象：A 协程刚 set 了一个请求 ID，B 协程还没读就覆盖了；日志里 trace_id 混乱，中间件拿不到当前请求上下文。
- 别在
async def函数里依赖threading.local存用户信息、DB 连接、认证 token -
contextvars是 Python 3.7+ 原生支持的协程安全方案，不需第三方库 - 它底层靠事件循环在协程切换时自动传播上下文，你不用手动传参或 patch
ContextVar 怎么声明和读写
每个变量必须提前声明为 ContextVar 实例，不能直接用普通全局变量替代。声明后，get() 和 set() 才能隔离到当前协程。
常见错误：把 ContextVar 当成普通对象赋值，或者忘记调用 get() 就直接用变量名。
- 声明：
request_id = ContextVar("request_id", default=None) - 写入：
request_id.set("req-abc123")（返回 token，一般不用存） - 读取：
request_id.get()，如果没 set 过且没设 default，会抛LookupError - 避免裸用
request_id——它不是值，是变量容器
在 asyncio 中如何确保上下文不丢失
协程之间通过 await 切换时，上下文默认是继承的；但一旦用了 loop.run_in_executor、多线程回调、或第三方库绕过 asyncio 调度，上下文就会断掉。
典型场景：用 concurrent.futures.ThreadPoolExecutor 跑阻塞 IO，结果子线程里 request_id.get() 返回 None 或旧值。
- 跨线程传递：用
contextvars.copy_context()拿当前上下文，在线程里用ctx.run(...)执行函数 - 避免在
run_in_executor回调里直接访问ContextVar - 第三方异步库（如 httpx、aiomysql）一般已适配 contextvars，但老版本或自定义封装要检查
和 asyncio.Task 配合时的坑
asyncio.create_task() 创建的任务会自动继承父协程的上下文，这点很省心；但如果你用 loop.create_task()（尤其在非 async 函数里），上下文可能为空。
更隐蔽的问题：任务被取消后，其上下文不会自动清理，但变量本身无状态，所以影响有限——真正麻烦的是你在 finally 或 except 里误读了残留值。
- 始终用
asyncio.create_task()，别用低阶loop.create_task() - 不要在
Task.cancelled()后还去读ContextVar，除非你明确知道它已被 reset - 调试时可打印
contextvars.copy_context().items()查当前上下文内容
contextvars 不是银弹——它解决的是“协程内局部状态隔离”，不是“跨服务传递”或“持久化”。真要透传，还是得靠 HTTP header、消息体字段或分布式 trace 系统。别指望一个 ContextVar 能从 FastAPI 接口一路跑到 Celery worker 里去。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
