线程内异常不会自动抛到主线程

Python 的 threading.Thread 启动后，如果子线程里发生未捕获异常，它只会打印 traceback 到 stderr，然后静默退出——主线程完全感知不到，join() 也不会报错。这是最常被误以为“程序跑完了没出错”的根源。

常见错误现象：
– 主线程正常结束，但子线程其实已崩溃
– 日志里有孤立的 Exception in thread ... 报错，却找不到对应逻辑断点
– 使用 concurrent.futures.ThreadPoolExecutor 时，future.result() 不调用就永远看不到异常

• 必须在每个线程函数内部加 try/except，把异常显式存起来（比如写进共享的 queue.Queue 或线程本地变量 threading.local()）
• 用 concurrent.futures.ThreadPoolExecutor 更省心：提交任务后，future.result() 会重新抛出子线程异常，但前提是你要主动调用它
• 别依赖 sys.excepthook 拦截线程异常——它在线程中默认不生效，得手动给每个线程设 threading.excepthook（Python 3.8+）

ThreadPoolExecutor 中的异常必须显式取

ThreadPoolExecutor.submit() 返回的是 Future 对象，它把异常“封印”在里面，不主动触发就不会暴露。很多人只提交任务、不检查结果，等于把 bug 埋进黑盒。

使用场景：
– 批量调用 API、读文件、处理队列任务
– 需要统一收口错误、做重试或降级

• 务必对每个 future 调用 future.result(timeout=...)，超时参数建议设值，避免卡死
• 多个 future 时，用 concurrent.futures.as_completed() 遍历，比循环调 .result() 更安全（能及时发现首个失败）
• 如果只关心是否成功，可用 future.exception() 判断是否有异常，但注意它返回 None 表示还没完成或没异常，不是“成功”

threading.Thread 的异常传递只能靠手动机制

原生 threading.Thread 没有内置异常回传机制，想让主线程知道子线程挂了，只能自己搭桥。硬塞全局变量容易冲突，推荐用线程安全的容器。

参数差异：
– threading.local() 是线程本地的，不能跨线程读取
– queue.Queue 线程安全，适合主线程等结果+异常
– concurrent.futures.Future 是更高层封装，但需配合 executor 使用

• 不要用普通 dict 或 list 存异常，多线程写入会丢数据或报 KeyError
• 用 queue.Queue 时，子线程放 (result, exception) 元组，主线程 get(timeout=...) 并检查 exception 是否为 None
• 如果线程可能长时间阻塞（如等待网络），记得给 Queue.get() 加 timeout，否则主线程可能永远等不到

print 和 logging 在多线程里不是原子操作

看似只是打日志，但 print() 底层是分步写 stdout 的，在多线程下容易出现字符交错，比如两行日志混成一行乱码。这不是异常捕获问题，但会让错误定位雪上加霜。

性能 / 兼容性影响：
– print() 在 CPython 中有 GIL 保护，但输出缓冲区仍可能被抢占
– logging 默认线程安全，但自定义 handler 或格式化器没加锁就会出问题

• 调试阶段别依赖 print() 查异常位置，优先用 logging.error(..., exc_info=True)
• 如果必须用 print()，套一层 threading.Lock，或者改用 print(..., flush=True) 减少缓冲干扰
• 所有日志消息里带上 threading.current_thread().name，能快速区分哪条日志来自哪个线程

线程异常真正的难点不在“怎么抓”，而在“怎么让主线程可靠地收到并响应”。很多坑都藏在异步边界上：你忘了取 result()，忘了设 timeout，或者以为 print 是安全的。这些地方一漏，问题就变成偶发、难复现、日志残缺。