Python asyncio协程共享全局命名空间但不共享执行上下文，模块级变量会被并发协程互相覆盖导致逻辑上下文污染；threading.local因绑定OS线程而在单线程协程中完全失效；ContextVar是唯一正解，需显式set/get/reset以实现请求级隔离。
asyncio 协程共享全局命名空间，但不共享执行上下文
Python 的 asyncio 在单线程内调度多个协程，所有协程都运行在同一个 Python 解释器进程里，因此直接读写的模块级变量（比如 current_user_id = None）是**物理共享的**。但协程切换不触发任何上下文隔离机制——A 协程刚给 current_user_id 赋值为 101，还没来得及用，就被 await 切走；B 协程进来覆盖成 202；等 A 恢复后读到的就是错的值。
这不是传统多线程里的“竞态条件”（没有 GIL 失效或内存可见性问题），而是**逻辑上下文污染**：你本想表达“这个请求的用户 ID”，结果变量绑在了模块上，而不是请求生命周期上。
threading.local 为什么在 asyncio 中完全失效
threading.local 依赖 OS 线程 ID 做键，而 asyncio 默认只用一个主线程跑所有协程。无论多少个 Task 并发，它们都在同一线程里来回切换，所以所有协程看到的是同一个 threading.local 实例。
- 你在 handler_a 里设
local.user_id = 101，handler_b 里读出来就是101，不是隔离的 - 即使你用
ThreadPoolExecutor把部分任务扔进子线程，主线程里的协程仍然共享 local 实例 - Pytest 或 mock 场景下更容易暴露：测试用例之间会互相污染
ContextVar 是唯一正解，但必须显式 set/get/reset
contextvars.ContextVar 不是魔法变量，它靠 asyncio 事件循环在 Task 切换时自动传播上下文对象。但你必须主动调用 .set() 和 .get()，否则它只是个空壳。
立即学习“Python免费学习笔记（深入）”；
- 声明：
request_id_var = contextvars.ContextVar('request_id', default=None) - 入口处设值：
token = request_id_var.set('A-001')（返回Token对象） - 业务中取值：
req_id = request_id_var.get() - 异常路径必须
reset(token)，否则上下文泄漏（尤其在中间件、装饰器里） - 不要在协程里反复
set()同一个 ContextVar——那是污染，不是更新
示例关键片段：
import contextvars
request_id_var = contextvars.ContextVar('request_id', default='unknown')
<p>async def handler():
token = request_id_var.set('A-001')
try:
await business()
finally:
request_id_var.reset(token) # 必须！
配置字典热更新时崩溃？不是并发写，是并发读写冲突
你以为只读配置很安全？错。如果另一个后台任务（比如配置监听器）在你遍历 config_dict.keys() 时调用了 config_dict.update(...)，就会触发 RuntimeError: dictionary changed size during iteration。因为 Python 的 dict 不是协程安全的，哪怕只是读，也怕被同时修改。
正确做法是用 types.MappingProxyType 做快照：
- 加载配置后生成不可变视图：
config_var.set(types.MappingProxyType(raw_config)) - 协程内始终
config_var.get()['timeout']，天然规避迭代中断 - 热更新时，只做原子替换：
config_var.set(new_proxy)，已运行协程继续用旧快照，这是优点而非缺陷
最易被忽略的一点：ContextVar 的 default 参数只在上下文为空时生效，一旦某处 set() 过，后续 get() 就不会回落到 default——所以别指望它兜底，得自己确保入口必设。
