contextvar 在 python 3.11 中完全可用且官方推荐，每个 task 自动继承父上下文，await 链中可直接 get()；create_task() 默认继承，但 call_soon、run_in_executor 等不继承，需 copy_context() 显式传递。
asyncio.ContextVar 在 Python 3.11 中是否可用？
完全可用，且是官方推荐的上下文变量方案。Python 3.7 引入 ContextVar，3.11 不仅保留，还强化了与 asyncio.Task 的集成——每个 Task 自动继承父任务或事件循环的上下文，无需手动传递。
常见错误是误以为要像线程局部存储那样“绑定”或“复制”，其实只要在 task 启动前设置，后续 await 链中直接读取即可：
import asyncio
from contextvars import ContextVar
<p>request_id = ContextVar("request_id", default=None)</p><p>async def handler():
print("ID:", request_id.get()) # ✅ 自动继承</p><p>async def main():
request_id.set("req-abc123")
await handler() # ID: req-abc123
</p>
为什么 await 后 ContextVar 值会丢失？
根本原因不是 Python 版本问题，而是上下文未被正确传播——典型场景有：用 loop.create_task() 或 asyncio.create_task() 时传入普通协程（非 async with 或 asyncio.TaskGroup），但更隐蔽的是在回调、信号处理或第三方库 hook 中脱离了 asyncio 上下文。
- ❌ 错误：用
loop.call_soon()或loop.run_in_executor()执行函数——这些不继承上下文，ContextVar.get()会回退到默认值 - ✅ 正确：改用
asyncio.to_thread()（3.9+）或显式在协程内捕获并传参 - ⚠️ 注意：
asyncio.create_task()在 3.11 中默认继承上下文，但若 task 被asyncio.shield()包裹后又取消，可能触发清理逻辑导致意外重置
如何安全地跨 Task 传递 ContextVar？
绝大多数情况不需要“传递”——新 task 默认继承调用点的上下文。但如果你在非 await 场景（如线程池回调、定时器、信号 handler）中需要访问，就必须显式携带。
推荐做法是把上下文快照封装进参数，而不是依赖全局状态：
import asyncio from contextvars import copy_context <p>ctx = copy_context() # 拍摄当前上下文快照 loop.run_in_executor(None, lambda: ctx.run(your_sync_func)) </p>
或者更稳妥地，在协程入口显式提取关键值传入子 task：
- 不要：在子 task 内直接调用
request_id.get()（可能为空） - 要：在父协程中
rid = request_id.get()，再asyncio.create_task(worker(rid)) - 适用场景：日志 trace_id、用户认证 token、数据库事务隔离级别等需强保证的字段
ContextVar 和 threading.local 有什么本质区别？
不是“类似替代”，而是设计目标完全不同：threading.local 绑定线程生命周期，ContextVar 绑定协程执行流（即 async stack）。在 asyncio 中混用会导致严重错乱——比如一个线程跑多个 event loop，或使用 asyncio.to_thread() 时，threading.local 的值会在不同协程间污染。
性能上，ContextVar 在 3.11 已优化为常量时间查找，比反复传参轻量，但比局部变量慢一个数量级。别把它当普通变量用，只存真正需要跨 await 边界透传的元数据。
最容易被忽略的一点：ContextVar 的 default 值不是“兜底”，而是上下文缺失时的 fallback——如果业务逻辑依赖该值（比如必须有 request_id），应该在入口处显式检查并抛异常，而不是靠 default 掩盖问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
