登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  python教程

Python contextvars.copy_context 如何隔离异步任务上下文:ContextVar 复制与回调边界

来源:17golang原创

时间:2026-08-30 13:26:45 178浏览 收藏

一个异步服务把请求编号放进 ContextVar 后,最容易误判的地方是:任务之间看起来共用一个变量,回调里又像是拿到了“当前请求”。真正决定结果的不是变量名,而是每个 asyncio.Task 持有的上下文,以及 copy_context().run() 临时切换的边界。

要点速览
  • asyncio 创建任务时会复制当前上下文,任务 A 设置的 req-A 不会覆盖任务 B 的 req-B
  • copy_context() 得到的是当前上下文的快照,Context.run() 返回后,调用方仍恢复原来的值。
  • 需要把请求信息交给同步回调时,用快照包住回调;需要长期共享数据时,不要把 ContextVar 当作全局配置。
  • 同一个 Context 不能在并发线程或任务中重复进入,跨线程执行前要重新设计边界。

先看一个请求编号为什么不会串到别的任务

下面的例子只做一件事:两个协程分别写入不同的请求编号,中间主动让出一次事件循环,再打印当前值。它和文章中的解释、截图完全是同一份 article_example.py

request_id = contextvars.ContextVar("request_id", default="-")

async def worker(name: str, value: str) -> None:
    request_id.set(value)
    await asyncio.sleep(0)
    print(f"task={name} request_id={request_id.get()}")
Python asyncio 两个任务分别输出 req-A 与 req-B 的真实终端结果
图1:核对两个 asyncio 任务的输出;A 保持 req-A、B 保持 req-B,说明任务上下文没有互相覆盖,下一步可以继续检查快照回调。

终端里应看到两行不同的编号。await asyncio.sleep(0) 只是制造任务切换机会,并不会把两个任务合并成同一个上下文。

ContextVar、copy_context 和普通全局变量怎么选

ContextVar 适合“随当前执行链传递,但不想层层改函数参数”的状态,例如请求编号、租户标识和 tracing 信息。它和普通全局变量的关键差异,是读取结果依赖当前上下文,而不是依赖最后一次写入者。

copy_context() 适合在一个明确的时间点拍快照。快照不是实时引用:原上下文之后再修改,已经复制出的 Context 不会自动跟着变化。对快照调用 run(callable) 时,回调会在快照里执行,回调结束后调用方恢复原上下文。

场景推荐做法验收信号
异步任务携带请求编号创建任务前设置 ContextVar不同任务打印各自编号
把当前值交给同步回调copied = copy_context() 后调用 copied.run()回调看到快照值,返回后原值不变
跨请求共享配置显式对象或配置中心修改来源和生命周期清楚

copy_context 的回调边界:进入快照,返回原现场

示例先把主协程中的值设为 main,再复制上下文。随后 inspect_context() 在复制出的上下文中运行。判断是否正确,不看函数返回值是否打印出来,而要同时看回调里的值和 run() 之后的值。

def inspect_context() -> str:
    return f"callback request_id={request_id.get()}"

copied = contextvars.copy_context()
copied_value = copied.run(inspect_context)
print(copied_value)
print(f"after_copy_run request_id={request_id.get()}")
Python copy_context 与 Context.run 回调先读到 main 返回后恢复 main 的真实终端结果
图2:重点看 callback 和 after_copy_run 两行;回调能在快照中读取 main,run 返回后调用方仍是 main,这就是上下文切换的边界。

这个边界很适合封装日志或同步适配器:调用方不必把请求编号作为额外参数传给每个回调,但回调仍能读取当时的上下文。要注意,快照只解决“在哪个上下文执行”,不负责把线程安全、资源释放或业务数据共享一起解决。

三个容易踩中的边界

不要用 ContextVar 代替共享配置

ContextVar 的值跟着执行上下文走。数据库连接池大小、功能开关和全局缓存属于应用配置,应该通过显式对象或配置层传递,否则测试和运维都会难以判断真正的来源。

不要让同一个 Context 重叠进入

一个 Context 在同一时间只能被一个执行流进入。并发执行同一个快照会破坏边界;需要并发时,为每个任务创建自己的上下文或在任务创建点设置变量。

修改后记得 reset token

在长期运行的同步代码里,token = request_id.set(value) 后应在 finally 中调用 request_id.reset(token),避免外层上下文被临时值污染。

常见问题

copy_context 会深复制业务对象吗?

不会。它复制的是上下文到变量值的映射;如果值本身是可变对象,仍要按共享对象的规则处理。

asyncio.create_task 会继承当前 ContextVar 吗?

会继承创建任务时的当前上下文。任务创建后,创建方再修改变量,不会反向改写已经运行任务的上下文。

为什么不直接把 request_id 作为参数传递?

边界清晰、调用链短时显式参数更容易测试;ContextVar 更适合日志、链路追踪这类横切信息,别用它隐藏核心业务输入。

把验收标准留在代码旁边

运行 python3 article_example.py 后,先确认 A/B 两个任务的编号不同,再确认 callback 和 after_copy_run 都是 main。前一组证明任务隔离,后一组证明快照回调结束后现场恢复;两组都成立,才说明这个示例的上下文边界完整。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>