threading.local 通过为每个线程维护独立属性字典实现变量隔离，主线程与子线程、子线程之间互不可见；需在线程内首次访问时初始化，避免主线程赋值或跨线程传引用，并注意线程复用时的清理。
threading.local 为什么能隔离变量？
它不是靠复制变量，而是为每个线程维护一个独立的属性字典。同一个 threading.local 实例，在线程 A 里赋值 local.x = 1，在线程 B 里读 local.x 就是未定义的——因为底层查的是当前线程专属的命名空间。
注意：主线程和子线程各自拥有独立副本，子线程之间也互不可见。这跟全局变量或类实例变量有本质区别。
正确初始化和赋值的写法
不能在创建 threading.local 后直接设属性，必须在线程内部首次访问时初始化。否则可能触发 AttributeError 或读到其他线程残留值（尤其在线程复用场景如 ThreadPoolExecutor 中）。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- ✅ 正确：每次使用前检查
if not hasattr(local, 'db_conn'):再创建连接 - ✅ 正确：用
getattr(local, 'counter', 0)避免 KeyError - ❌ 错误：在主线程中写
local.user_id = 123，期望子线程能继承这个值 - ❌ 错误：把
local当成普通对象传给target函数后直接修改属性（传的是引用，但属性不跨线程生效）
常见踩坑：和 ThreadPoolExecutor 搭配时变量“消失”
线程池会复用线程，而 threading.local 对象本身是共享的，但其内部状态随线程生命周期存在。如果某次任务没清理干净（比如开了数据库连接没关），下次复用该线程时，local 里可能还挂着旧连接。
立即学习“Python免费学习笔记（深入）”；
- 务必在任务末尾显式清理：例如
delattr(local, 'db_conn')或设为None - 更稳妥的做法是用
try/finally包裹关键资源，确保释放 - 避免在
local中存大对象（如缓存字典），长期驻留会增加内存压力 - 调试时可打印
threading.get_ident()辅助确认是否真正在不同线程里运行
对比：threading.local vs 函数参数传值
当多个函数嵌套调用都需要访问某个上下文（如请求 ID、用户信息），用 threading.local 可避免层层透传参数，但代价是隐式依赖和更难测试。
- 适合场景：Web 框架中间件注入 request context、日志 trace_id 注入
- 不适合场景：需要精确控制生命周期的资源（此时应优先考虑 contextvars（Python 3.7+））
-
contextvars是协程安全的，而threading.local在 asyncio 中不适用——哪怕你在 thread 中跑 asyncio.run()，也不能跨 task 共享 local 变量 - 性能上差异极小，但
contextvars的 get/set 略快于threading.local的属性访问
