生产环境禁用无参join()，必须设超时（如join(timeout=3)）并检查is_alive()；子线程需带timeout的阻塞调用、主动退出信号检测与心跳日志；非关键线程设daemon=True兜底。

主线程调用无参 join() 时，若子线程陷入死循环（比如无限等待某个未被触发的事件、空转 while True、或阻塞在无超时的 queue.get() / event.wait() 上），主线程就会永久挂起——这不是死锁（没有多个锁循环等待），而是“单点阻塞假死”，但对服务的影响等同于全线不可用。

关键：永远别用无参 join()

无参 join() 意味着“等它到天荒地老”。生产环境必须加超时：

• 用 thread.join(timeout=3) 显式设一个合理上限（如 2~5 秒）
• 超时后检查线程是否还存活：thread.is_alive()
• 若仍存活，说明它卡住了——应记录告警、尝试清理资源，而不是继续等

子线程自身必须有退出路径和心跳机制

不能依赖外部“喊停”就一定能退出。子线程逻辑需主动配合：

• 所有阻塞调用（event.wait()、queue.get()、socket.recv()）都带 timeout 参数
• 主循环内定期检查退出信号（如 self._stop_event.is_set()），不能只在循环头判断
• 加入轻量级心跳日志（例如每 10 秒打一行 INFO: worker still alive），便于监控异常停滞

用守护线程 + 超时 join 组合兜底

对非关键、可丢弃的子线程，启动前设为守护线程：

• thread.daemon = True
• 这样即使主线程因异常退出，子线程也会被强制终止，避免残留
• 配合 join(timeout=...)，既防卡死，又保 graceful shutdown 尝试

上线前做阻塞点扫描和压测验证

人工或静态检查代码中所有可能阻塞的位置：

• threading.Event.wait() → 必须带 timeout
• queue.Queue.get()/put() → 明确设 timeout，避免默认阻塞
• 第三方 SDK 调用（如 requests、redis-py）→ 查文档确认是否有默认无限等待，显式传 timeout=(3, 7)
• 压测时模拟网络延迟、下游超时、事件未触发等场景，验证子线程能否在超时内响应并退出