科技 · 实用指南
Python ContextVar 在线程池中丢失？厘清上下文传播与修改回传
区分异步任务、to_thread、线程池与进程：每次提交线程任务时复制上下文，并显式返回修改结果。
ContextVar 跨越不同并发边界时，行为并不相同。asyncio Task 保留任务自身的上下文，asyncio.to_thread 会把当前 Context 复制到工作线程；直接提交给 ThreadPoolExecutor 或调用 loop.run_in_executor 时，若框架没有代为处理，就需要显式复制。
把上下文传入工作线程，与把线程内的修改带回调用方，是两件事。每次提交都捕获一份新副本，在副本中执行一次调用；需要带回的修改应作为结果返回。跨进程时另行传递数据，并用两个并发请求验证隔离。
1. 先确认调用跨越了什么边界
记录调用是在 asyncio Task 内执行，使用 asyncio.to_thread，调用 loop.run_in_executor，直接提交给 ThreadPoolExecutor，还是进入另一个进程。不要仅凭函数名或框架名称推断行为。
在边界两侧记录一个不含敏感信息的请求标记。标记缺失说明传播未成功；出现上一请求的值说明工作线程残留了状态；仅在显式复制后才出现预期值，则说明传播由包装层承担。
2. 每次提交线程任务时复制上下文
直接提交线程任务时，在发起请求的上下文中执行 ctx=contextvars.copy_context()，再提交 ctx.run、目标函数及其参数。每次提交都要捕获副本，不要只在创建长期使用的线程池时复制一次。
不要让两个工作线程同时进入同一个 Context：重复进入已经处于执行状态的上下文会触发 RuntimeError。每次调用使用新副本，也能确保捕获的是当前请求的状态，而不是线程池启动时的状态。
3. 把传入上下文和回传修改分开
asyncio.to_thread 明确提供向工作线程传播上下文的行为；框架辅助函数也可能围绕 run_in_executor 做相同包装。但这并不意味着工作线程中的 ContextVar 赋值会自动写回等待它的 Task。
如果工作线程算出了新的租户、追踪跨度或授权结果，应把它作为普通数据返回，由调用方决定是否设置或重置自己的 ContextVar。临时覆盖调用方状态时，保存 set() 返回的 token，并在 try/finally 中调用 reset() 恢复。
4. 分别处理线程和进程
CPython 讨论没有为 run_in_executor 采用统一的自动传播规则，原因之一是它也可以使用 ProcessPoolExecutor，而 Context 对象不能通过 pickle 序列化。不要把只适用于线程的包装方式套到进程边界上。
跨进程时，显式传入小型、可序列化的请求上下文，在工作进程中验证，并明确返回结果。凭据和大型可变对象应遵守进程接口的安全及所有权规则，不能把它们当成可随处读取的 ContextVar 状态。
5. 用实际调用路径验证请求隔离
通过实际生产环境使用的辅助函数，发起标记分别为 A、B 的两个重叠调用，并用同步屏障确保两个工作线程同时活跃。确认 A 只看到 A、B 只看到 B，未包装的对照调用则得到文档约定的默认值。
让两个工作线程分别设置不同的局部值并返回。await 或 Future.result() 之后，确认调用方仍保留原标记，直到它主动修改或重置。错误处理和关闭路径也应重复检查，避免线程池残留上一请求的值。
