threading.Thread 的异常不会跨线程传播，主线程中 try/except 无法捕获子线程异常；可靠方案是继承 Thread 重写 run/join 保存并重抛异常，或使用 ThreadPoolExecutor 调用 future.result() 直接 re-raise。
threading.Thread 的异常根本不会跨线程传播
主线程里用 try/except 包住 t.start() 或 t.join() 完全无效，因为子线程的异常和主线程处于完全隔离的执行上下文。Python 的线程模型不提供自动异常转发机制——start() 只是启动线程，不等待；join() 只是阻塞等待结束，但不会把子线程的 Exception 重新抛给主线程。
常见错误现象：异常被静默吞掉
你看到的现象通常是：
- 子线程里
raise ValueError("boom")，但主线程毫无反应，程序看似“正常退出” -
try: t.join() except Exception as e:语句块根本没进except - 日志里没报错，调试器断点也停不到异常位置，只能靠
print()硬查
为什么不能依赖 sys.excepthook
有人试图在子线程里改 sys.excepthook，但这不可靠：
- 每个线程有独立的
sys模块副本，主线程设的钩子对子线程无效 - 子线程异常未被捕获时，确实会触发其自身的
excepthook，但默认行为只是打印 traceback 后退出，不中断主线程，也不留下可检查的状态 - 钩子执行时机在线程即将销毁前，此时主线程可能早已继续运行，无法同步响应
真正能用的两种实操方案
必须主动建立异常传递通道：
立即学习“Python免费学习笔记（深入）”；
- 继承
threading.Thread，重写run()和join()：在run()里try/except捕获并存到实例属性（如self._exc），再让join()在返回前检查并raise self._exc - 用
concurrent.futures.ThreadPoolExecutor：提交任务后调用future.result()，它会在内部等待完成并**直接 re-raise 子线程异常**，无需手动存取
注意：ThreadPoolExecutor 的 as_completed() + future.exception() 是更轻量的检查方式，适合不想被异常中断执行流的场景。
