子线程异常默认不会传播到主线程，仅打印traceback后静默退出；推荐用threadpoolexecutor，调用future.result()可原样抛出异常；若必须用thread，需手动捕获并存储sys.exc_info()供主线程检查。
子线程异常默认不会传播到主线程
Python 的 threading.Thread 启动后，如果子线程内抛出未捕获异常，它只会打印 traceback 到 sys.stderr，然后静默退出——主线程完全感知不到，更不会中断或重抛。这是最常被误以为“程序挂了但没报错”的根源。
常见错误现象：Thread 对象的 join() 返回后，主线程继续执行，但子任务其实已因异常失败；日志里只有孤立的 traceback，没有上下文，难以定位是哪个线程、哪个参数导致的问题。
根本原因：每个线程有独立的异常处理栈，C Python 的线程模型不支持跨线程异常传递（不像 asyncio 或 concurrent.futures 那样封装了传播逻辑）。
用 concurrent.futures.ThreadPoolExecutor 替代裸 Thread
这是目前最轻量又可靠的方案。它把异常捕获和传播封装进 Future 对象，主线程调用 result() 时会原样 re-raise 子线程异常（包括类型、消息、traceback）。
实操建议：
- 不要手动创建
Thread，改用ThreadPoolExecutor(max_workers=...)管理线程池 - 提交任务用
submit(func, *args, **kwargs)，返回Future对象 - 必须显式调用
future.result()（或as_completed()中遍历），否则异常不会抛出 - 若多个任务并发，可用
executor.map()，它会在第一个异常发生时立即停止并抛出（类似内置map）
示例：
from concurrent.futures import ThreadPoolExecutor
import time
<p>def risky_task(x):
if x == 2:
raise ValueError("boom on input 2")
return x * x</p><p>with ThreadPoolExecutor() as executor:
futures = [executor.submit(risky_task, i) for i in [0, 1, 2, 3]]
for future in futures:
try:
print(future.result()) # ← 这里会触发 ValueError
except ValueError as e:
print(f"Caught: {e}")
</p>
自己封装 Thread 类时如何安全捕获异常
如果必须用原生 Thread（比如需要精确控制生命周期、或集成旧代码），就得手动把异常存下来，再由主线程检查。
关键点：
- 在线程函数内部用
try/except捕获所有异常，并存入线程实例的属性（如self.exc_info = sys.exc_info()） - 重写
run()方法，确保异常路径也能设置该属性 - 主线程中调用
join()后，检查该属性是否非空，再用raise exc_info[1].with_traceback(exc_info[2])原样抛出 - 注意：不能直接存异常对象（会引发循环引用），推荐用
sys.exc_info()元组或traceback.format_exc()字符串
性能影响：几乎为零；兼容性无问题，适用于所有 Python 版本。
别踩这些坑
容易忽略但后果严重的问题：
-
ThreadPoolExecutor.shutdown(wait=True)不会帮你检查异常——它只等线程结束，异常仍需手动调result() - 用
queue.Queue传异常时，记得在子线程里调queue.put_nowait((False, exc))，否则阻塞可能导致主线程死等 -
threading.excepthook是全局钩子，仅用于日志记录，无法中断主线程或改变控制流 - 在 Jupyter 中测试时，
Future.result()抛出的异常可能被 notebook 拦截显示不全，建议加import traceback; traceback.print_exc()辅助调试
真正麻烦的不是怎么捕获，而是忘记“主动拉取结果”这个动作——只要没调 result() 或没查自定义异常字段，异常就永远沉在子线程里，像没发生的那样。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
