threading.local() 通过为每个线程维护独立哈希表实现线程私有，键为 local 实例 id、值为线程专属数据；访问时自动按当前线程 id 查表，故不同线程互不干扰且无继承关系。
threading.local() 是怎么做到“线程私有”的
它不是靠复制变量，而是在线程对象内部维护一张哈希表，键是 local 实例的 ID，值是你存进去的数据。每次访问 local 的属性，Python 底层会自动查当前线程的这张表——换线程就查另一张，自然隔离。
这意味着：同一个 local 实例，在不同线程里读写完全不冲突；但主线程里初始化的值，不会自动“继承”给子线程——子线程第一次访问时，对应 key 根本不存在，所以是干净的空状态。
- 不要在主线程里给
local赋初始值，指望子线程能用上——它们看不到 -
local实例本身可以全局定义，但它的属性必须在线程内首次访问时设置 - 底层依赖
threading.get_ident()作为线程标识，所以协程（如 asyncio）里不能用——它和 OS 线程不是一一对应的
为什么 hasattr(local, 'x') 在新线程里返回 False
因为 hasattr 底层调用的是 getattr + 异常捕获，而新线程里 local.x 根本没被设过，触发 AttributeError，于是返回 False。这不是 bug，是设计使然：每个线程的属性空间完全独立，没有“默认存在”这回事。
常见误用是想用 hasattr 判断变量是否已初始化，结果在子线程里永远进不到 if 分支。
立即学习“Python免费学习笔记（深入）”；
- 正确做法是：在线程入口处显式检查并初始化，比如
if not hasattr(local, 'db_conn'): local.db_conn = connect_db() - 更稳妥的是用
try/except AttributeError，比hasattr少一次属性访问开销 - 别依赖
dir(local)查属性——它只返回当前线程里的键，其他线程的看不见，也别想用它做跨线程调试
local 对象的生命周期和内存泄漏风险
threading.local 不会自动清理线程退出后的数据。如果线程是长期存活的（比如线程池里的 worker），那它绑定的 local 数据会一直占着内存，直到线程结束。而 Python 的线程退出时，会自动清掉该线程名下的 local 值——但前提是线程真的结束了，而不是被池复用。
- 线程池场景下，务必在任务结尾手动清理：用
delattr(local, 'key')或直接设为None - 避免在 local 上挂大对象（如缓存字典、文件句柄），尤其不要存引用了外部长生命周期对象的结构
- 可以用
weakref包一层来缓解，但注意 weakref 本身不解决属性访问逻辑，只是延缓回收时机
替代方案：什么时候不该用 threading.local
当你需要的是“请求级隔离”而非“线程级隔离”，比如在异步 Web 框架（FastAPI/Starlette）里传上下文，threading.local 完全失效——asyncio 事件循环里一个线程跑多个协程，get_ident() 返回的还是同一个 ID。
- async 场景用
contextvars.ContextVar，它是为协程设计的，支持 context propagation - 简单函数传参比 local 更可控，尤其当逻辑不深、线程/协程切换明确时
- 如果只是临时存点东西，考虑用函数参数或闭包，比引入 local 更轻量、更易测试
local 看似简单，但它的“透明性”恰恰是最容易埋坑的地方：你感觉不到它在背后做了什么，直到某个线程行为异常、内存涨得莫名其妙、或者协程里突然拿到别人的值。
