contextvars 在 asyncio 中无法自动传递到新任务是因为 create_task() 创建时仅拷贝当前上下文快照，后续父协程修改不影响子任务；需显式传参或 python 3.12+ 的 context 参数。
contextvars 在 asyncio 里为什么传不下去
因为 asyncio.create_task() 启动的新任务默认不继承父协程的 ContextVar 值——这不是 bug，是设计使然：每个任务有独立上下文快照，创建时只拷贝当前值，后续父协程改了，子任务看不到。
常见错误现象：ContextVar.get() 在子任务里返回默认值或 Token.missing，而你在 await 前明明 set() 过。
- 必须在创建任务前完成
var.set()，且用asyncio.create_task(coro, name=...)的方式（Python 3.12+ 支持显式传 context，但旧版不行） - 更稳妥的做法是把值作为参数显式传入协程，而不是依赖上下文自动传递
- 如果用
loop.create_task()或第三方库（如 aiohttp 的spawn），要确认它是否调用了contextvars.copy_context()
如何安全地跨 await 边界保留 contextvar 值
ContextVar 本身是线程/协程安全的，但在 await 暂停点，控制权交还事件循环，此时若其他协程修改了同一 ContextVar，你 resume 后读到的可能是别人设的值——除非你用的是当前协程专属上下文副本。
使用场景：日志 trace_id、用户认证信息、数据库事务上下文等需要贯穿整个协程生命周期的轻量状态。
立即学习“Python免费学习笔记（深入）”；
- 始终用
var.get()读，不要缓存返回值；每次读都是当前上下文的实时快照 - 避免在
finally或__aexit__里调用var.reset(token)时传错 token（token 必须是对应那次set()返回的） - 不要在非 async 函数里
set()后直接await，除非你知道当前运行在哪个 context 中（比如被asyncio.run()包裹的顶层协程）
和 threading.local 对比时容易踩的坑
threading.local 是按线程隔离，contextvars 是按协程（更准确说是 contextvars.Context 实例）隔离——但一个线程可以跑多个协程，一个协程也可能被调度到不同线程（虽然 asyncio 默认不这样）。
典型错误：把 contextvars 当成“async 版 local”，然后在线程池（loop.run_in_executor）里访问，结果读不到值。
-
run_in_executor中的代码运行在普通线程，没有 asyncio 上下文，var.get()永远拿不到协程里设的值 - 需要传值，只能靠参数或
concurrent.futures.Executor.submit(fn, *args)显式带过去 - 如果必须共享状态，考虑用
asyncio.Lock+ 普通 dict，而不是依赖 contextvars
Python 3.7–3.11 的兼容性注意点
contextvars 模块从 3.7 加入，但早期版本（尤其 3.7.0–3.7.2）有 context 泄漏和 reset 失败的问题；3.9 修复了多数 corner case，3.11 开始支持 Context.copy() 和更好的调试接口。
性能影响很小，但要注意：频繁 set()/reset() 不会触发 GC，但每个 set() 都生成新 token，大量短命协程可能增加小对象分配压力。
- 生产环境建议至少用 Python 3.9+，避开已知 context 丢失 bug
- 不要在 hot path（如每请求都新建几十个协程）里反复
set()同一个ContextVar，优先复用或延迟初始化 - 调试时可用
contextvars.copy_context()打印当前所有变量，但别在压测中留着
真正难的不是怎么设，是怎么确定该不该用 contextvars——它适合贯穿单次请求的隐式状态，不适合跨服务、跨线程、或需要强一致性的数据。一旦出现“为什么这里值变了”这种问题，八成是忘了 reset，或者误以为它能穿透 executor。
