多级继承中重写run()导致上下文丢失，本质是contextvars未随控制流正确传递或隔离；需用copy_context()验证上下文是否传入子类，检查是否跨协程/线程，重写时应调用super().run()或显式绑定context.run()。
多级继承中重写 run() 方法导致上下文丢失，本质不是“视觉死结”，而是上下文变量（contextvars）未随控制流正确传递或隔离所致。关键不在方法名本身，而在执行路径是否处于同一 Context，以及子类是否无意覆盖/绕过了父类建立上下文的逻辑。
确认上下文是否真的被丢弃
先别急着改 run()，用 contextvars.copy_context() 快速验证：
- 在父类
run()开头打印list(copy_context().items()) - 在子类重写的
run()开头同样打印 - 对比两处输出：如果子类里为空或缺少关键
ContextVar，说明上下文没传进来；如果一致，问题可能出在后续异步调用或线程切换中
检查 run() 是否在新协程或新线程中启动
contextvars 不跨协程、不跨线程自动传播。常见陷阱：
- 父类
run()是同步方法，但子类把它改成async def run(self)，却没用await调用父类逻辑，而是另起一个asyncio.create_task()—— 新 task 拥有独立空上下文 - 子类在
run()中调用了threading.Thread或concurrent.futures.Executor—— 子线程默认无上下文，需手动拷贝：ctx = copy_context(); thread = Thread(target=ctx.run, args=(func,)) - 用了
asyncio.to_thread()或loop.run_in_executor()却没显式传入当前上下文
重写时保留上下文注入点
如果父类 run() 的作用之一是初始化上下文（比如设置请求 ID、用户身份等），子类不能只写功能逻辑，必须主动延续：
- 不要完全替换父类逻辑，优先用
super().run()触发上下文准备 - 若必须自定义流程，把父类上下文设置逻辑抽成单独方法（如
_setup_context()），在子类run()开头显式调用 - 对异步场景，用
contextvars.Context.run()显式绑定：ctx.run(super().run)，确保父类行为在当前上下文中执行
避免在 __init__ 或属性访问中隐式依赖上下文
有些类会在 __init__ 里读取 contextvar.get()，但此时上下文尚未建立（尤其多级继承中父类 __init__ 先于子类 run() 执行）。解决方式：
- 把上下文敏感的初始化延迟到
run()或首次使用时（懒加载） - 在
__init__中只存 raw value，真正解析留到run()里做 - 若必须初始化，让父类
__init__接收可选的context=None参数，由子类在准备好后传入
