Python 中 threading.Thread 子线程崩溃不影响主线程，因异常默认不传播；需继承 Thread 重写 run 和 join，或改用 ThreadPoolExecutor 通过 future.result() 获取异常。

threading.Thread 创建的子线程崩溃后，主线程照常运行——这不是 bug，是 Python 的设计事实。因为线程异常默认不传播、不中断、不通知，主线程根本“感觉不到”子线程挂了。

---

threading.Thread 的异常默认被吃掉

• 子线程中未捕获的异常会终止该线程，但解释器不会报错、不打印 traceback（除非启用了 threading.excepthook，而它默认是空的）
• 主线程调用 t.start() 后，无论子线程是否抛出 RuntimeError 或 ValueError，都不会影响主线程继续执行
• 常见错误现象：日志没输出、任务静默失败、join() 正常返回、程序看似“跑完了”，实则关键逻辑根本没执行

你不能靠「主线程 try-except 包裹 start()」来捕获子线程异常——那根本捕不到。

---

重写 Thread 类让 join() 抛异常

最轻量、可控的修复方式是继承并增强 threading.Thread：

• 在 run() 中包裹 try-except，把异常存到实例属性（如 self._exc）

  立即学习“Python免费学习笔记（深入）”；

• 必须重写 join()：只有在这里检查 self._exc 并 raise，异常才能真正冒泡到主线程上下文

• 示例关键片段：

  

  librosa Python 音频与音乐分析库

  librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。

  下载

  class ExceptionThread(threading.Thread):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._exc = None
  <p>def run(self):
  try:
  super().run()
  except Exception as e:
  self._exc = e</p><p>def join(self, *args, *<em>kwargs):
  super().join(</em>args, **kwargs)
  if self._exc:
  raise self._exc

注意：如果多个线程并发 join()，异常只在对应线程的 join() 调用点抛出，不是集中式收集。

---

用 concurrent.futures.ThreadPoolExecutor 统一收异常

比手写线程类更推荐生产环境使用：

• 提交任务返回 Future 对象，异常被封装进对象内部

• 调用 future.result() 时才真正抛出子线程异常（同步阻塞等待）

• 支持超时、批量等待（as_completed）、自动资源清理

• 示例：

  from concurrent.futures import ThreadPoolExecutor
  def risky():
      raise ValueError("boom")
  <p>with ThreadPoolExecutor() as ex:
  f = ex.submit(risky)
  try:
  f.result()  # ← 这里才 raise ValueError
  except ValueError as e:
  print("got it:", e)

别忘了：不调 result() 或 exception()，异常就一直“沉”在 Future 里，不会自动浮现。

---

容易被忽略的关键点

• sys.excepthook 对子线程无效；要捕获线程内未处理异常，必须在线程自己的栈里做 try-except
• 守护线程（daemon=True）崩溃后主线程退出时，异常根本来不及上报——别依赖 daemon 做错误兜底
• 多个子线程都可能出错，但 ThreadPoolExecutor 的 as_completed() 是逐个返回，需循环检查每个 future.exception() 才不会漏掉
• 如果你用的是异步 I/O（asyncio），这套线程方案不适用；那是另一套异常传播机制