asyncio.run()每次创建全新上下文，外部set()对内部协程无效；正确做法是在main协程内set()，或用Context().run()显式传递。
为什么 asyncio.run() 里设的 ContextVar 在子协程里读不到
因为 asyncio.run() 每次都会创建全新上下文，你在它外面或回调里用 var.set()，对内部协程完全无效。正确做法是：所有 set() 必须发生在 asyncio.run() 启动的主协程内部，或通过 contextvars.copy_context() 显式传递。
- 错误写法：
import contextvars var = contextvars.ContextVar('id', default=None) var.set(123) # 这个 set 对 run() 内部协程无效 asyncio.run(main()) - 正确写法：
async def main(): var.set(123) # 在协程体内 set await subtask() <p>asyncio.run(main())</p> - 若需从同步入口传值（如 Web 框架中间件），用
contextvars.Context().run()包裹整个协程调用
asyncio.create_task() 会继承当前上下文吗
会，但仅限于调用 create_task() 时的上下文快照。之后父协程修改 ContextVar，子任务看不到——这是预期行为，不是 bug。
- 子任务启动后，它的上下文就固定了；
var.set()只影响当前上下文及其后续派生，不影响已存在的 task - 如果需要动态透传，得在子任务里重新
get()并显式传参，或改用asyncio.TaskGroup+ 外部变量捕获 - 注意：
asyncio.ensure_future()行为相同，但loop.create_task()（旧 API）不保证上下文继承，尽量避免
Web 框架中用 ContextVar 存 request ID 为什么有时丢失
常见于中间件未 await、或用了线程池（loop.run_in_executor）却没手动拷贝上下文。Python 的 ContextVar 不跨线程，也不跨未 await 的协程边界。
- Flask-SQLAlchemy 或 FastAPI 中间件里，必须确保
await到底，不能漏掉await call_next() - 在
run_in_executor里使用前，先ctx = contextvars.copy_context()，再ctx.run(...) - 检查是否误用了
threading.local替代ContextVar——后者才是 asyncio 原生方案，前者在协程切换时必然失效 - 调试技巧：在关键点打印
var.get(None)，确认是否为None；如果是，说明上下文断了
多个 ContextVar 一起用要注意什么
每个 ContextVar 独立管理，但共享同一上下文对象。问题通常出在生命周期和默认值设计上。
- 避免给
ContextVar设可变默认值（如default=[]），否则所有上下文会共享这个 list - 不要在模块顶层
var.get()，那会触发全局默认值，掩盖上下文缺失问题 - 高并发下频繁
set()/get()几乎无性能开销，但滥用copy_context()（比如每毫秒一次）会有明显分配压力 - 调试时可用
contextvars.Context().items()查看当前所有变量值，但仅限开发环境，别放生产
实际项目中最容易被忽略的，是把 ContextVar 当成全局变量来用，或者以为它能自动穿透 run_in_executor 和第三方库的异步封装。它只在标准 asyncio 协程链路里可靠，一旦涉及线程、C 扩展、或非标准事件循环，就得自己接管上下文流转。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
