Python 3.7+版本下选择threading.local()而非ContextVar的原因是什么

一、二者并非只有async支持这一项实际差异，核心差异还包括： #

• 状态绑定粒度不同：thread-local 绑定操作系统线程，ContextVar 绑定逻辑执行上下文——上下文可以是线程，也可以是协程，还支持自定义快照复制、跨调用传递。
• 上下文继承逻辑不同：thread-local 状态默认完全隔离，子线程不会继承父线程的 thread-local 值；ContextVar 默认在创建子任务（协程/线程子任务均适用）时自动继承父上下文的变量值，仅手动创建空白上下文时才会中断继承。
• 原生重置能力不同：ContextVar 内置reset()方法，调用set()时返回的token可用来精准恢复变量到之前的状态，非常适合临时修改后回滚的场景；thread-local 没有原生重置机制，需要自行存储旧值才能实现相同效果。
• API 设计差异：thread-local 使用时直接给threading.local()实例动态加属性即可，无需提前声明；ContextVar 要求提前显式声明变量实例，再通过get()/set()方法读写，对类型提示的适配更友好。
• 性能差异：thread-local 读写速度比 ContextVar 快30%~50%，底层实现更轻量，没有上下文继承、切换的额外开销，纯线程高并发场景下性能差距会更明显。

二、即使目标环境是Python 3.7+，也不是所有原 thread-local 场景都适合改用ContextVar #

如果你的代码完全没有async逻辑，后续也没有接入协程的计划，同时对性能比较敏感，完全不需要替换。thread-local API更简单，没有额外学习成本，也不会引入不必要的性能开销。

三、除了明确需要将状态与线程绑定的场景外，仍有这些理由优先选择thread-local： #

• 代码为纯同步多线程架构，完全不会用到asyncio/协程，追求极致的读写性能
• 不需要上下文继承能力，甚至明确不希望子任务继承父线程的状态，thread-local的默认隔离逻辑更贴合需求
• 现有代码已经大量使用thread-local，迁移到ContextVar会带来额外的改造成本和回归风险，且没有明确收益
• 依赖的第三方库内部基于thread-local实现，替换为ContextVar会出现兼容问题

小提示：如果你的代码有接入协程的计划，或者需要跨逻辑执行上下文传递链路状态（比如请求ID、用户身份等），优先选ContextVar是更合理的选择。

内容的提问来源于stack exchange，提问作者Graham Lea