在 pyside6 中，直接调用 `qthread.quit()` 无法强制中断正在执行的 python 函数；需通过协作式中断机制（如标志位 + 定期检查）或更底层的线程控制（如 `threading` 模块异常注入）实现可靠退出。

在 PySide6（或 PyQt）中，QThread.quit() 仅用于退出事件循环（event loop），而非终止正在运行的 Python 代码。如果你的 Worker.generate() 是一个纯计算型、无事件循环、无 QThread.sleep()/QThread.usleep()/QApplication.processEvents() 调用的长任务（例如循环处理大量数据、调用阻塞式第三方库函数），那么 quit() 和 wait() 将完全无效——线程会继续执行直到函数自然返回，UI 主线程则因 wait() 被阻塞而冻结，最终触发 QThread: Destroyed while thread is still running 错误。

✅ 推荐方案：协作式中断（推荐首选，安全、标准、可维护）

这是 Qt 官方推荐且最健壮的方式：不强行杀死线程，而是让工作线程主动、及时响应“停止请求”。

步骤如下：

1. 在 Worker 类中添加原子性停止标志（使用 QAtomicInt 或线程安全的 bool + QMutex）：

   from PySide6.QtCore import QObject, Signal, QAtomicInt
   
   class Worker(QObject):
       finished = Signal(str)
       update_text = Signal(str)
       get_choice = Signal(str)
   
       def __init__(self, parent, question, threshold, verbose):
           super().__init__(parent)
           self.question = question
           self.threshold = threshold
           self.verbose = verbose
           self._stop_requested = QAtomicInt(0)  # 0 = running, 1 = stop requested
   
       def request_stop(self):
           self._stop_requested.storeRelaxed(1)
   
       def is_stop_requested(self):
           return self._stop_requested.loadRelaxed() == 1
   
       def generate(self):
           try:
               # 模拟长任务：分块处理 + 定期检查停止信号
               for i in range(1000000):
                   # 关键：高频检查中断请求（尤其在耗时操作前后）
                   if self.is_stop_requested():
           
               self.finished.emit("Task cancelled by user.")
                       return
   
                   # 实际业务逻辑（例如：文本处理、模型推理等）
                   if i % 10000 == 0:
                       self.update_text.emit(f"Processing... {i//10000}%")
   
                   # 若存在阻塞调用（如 time.sleep），替换为带检查的循环
                   # time.sleep(0.01) → 改为：
                   # for _ in range(10):
                   #     QThread.msleep(1)
                   #     if self.is_stop_requested(): return
   
               self.finished.emit("Task completed successfully.")
           except Exception as e:
               self.finished.emit(f"Error: {str(e)}")

2. 在 CLD 类中连接“Back”按钮，并正确清理线程：

   def __init__(self, question, threshold=0.85, verbose=True):
       # ...（原有初始化代码）
       self.worker = Worker(self, question, threshold, verbose)
       self.thread = QThread()
       self.worker.moveToThread(self.thread)
   
       # 连接信号（注意：finished 是 worker 自定义信号，非 QThread.finished）
       self.worker.finished.connect(self.on_finished)
       self.worker.update_text.connect(self.display_area.append)
       self.worker.get_choice.connect(self.enter_choice)
       self.thread.started.connect(self.worker.generate)
   
       # Back 按钮（假设你已创建 QPushButton 并命名为 back_button）
       self.back_button.clicked.connect(self.abort_task)
   
   @Slot()
   def abort_task(self):
       # 1. 请求 worker 停止
       self.worker.request_stop()
       # 2. 可选：禁用按钮防重复点击
       self.back_button.setEnabled(False)
       self.run_button.setEnabled(True)  # 恢复主操作按钮
   
   @Slot(str)
   def on_finished(self, response):
       self.display_area.append(response)
       self.run_button.setEnabled(True)
       self.back_button.setEnabled(True)
       # 3. 安全退出线程（此时 worker 已自然返回，事件循环可安全退出）
       self.thread.quit()
       self.thread.wait()  # 现在 wait 不会卡住！
       # 4. 发射返回信号（如需跳转回上一窗口）
       self.back_signal.emit()

⚠️ 重要提醒： ❌ 不要调用 QThread.terminate() —— 它是危险的、不可移植的，可能导致资源泄漏或崩溃； ❌ 不要在 generate() 中直接 return 后立即 quit() —— quit() 必须由 started 信号所触发的上下文之外调用（即不能在 generate() 内部调用 self.thread.quit()）； ✅ QAtomicInt 比普通 bool 更线程安全，避免竞态条件； ✅ 在循环体内部、I/O 操作前后、计算密集段落之间插入 is_stop_requested() 检查，频率越高，响应越及时。

⚠️ 替代方案：threading 异常注入（仅限特殊场景）

如原答案所述，使用 Python 原生 threading 模块配合 sys._current_frames() 和 threading.Thread._stop()（已废弃）或 ctypes.pythonapi.PyThreadState_SetAsyncExc 手动抛出异常，虽能“强行中断”，但存在严重风险：

• 可能破坏解释器状态（如中断在内存分配、GIL 切换关键点）；
• 无法保证资源（文件句柄、数据库连接）被正确释放；
• 在 PySide6 中易与 Qt 事件循环冲突，导致未定义行为；
• PySide6 官方明确不支持该方式，且 PyThreadState_SetAsyncExc 在现代 Python 版本中已被限制使用。

因此，除非你完全掌控底层 C 扩展逻辑且有充分测试，否则强烈不建议在生产 UI 应用中采用此方案。

总结

始终牢记：Qt 的线程模型是基于事件驱动的协作式并发，而非抢占式多任务。尊重这一设计哲学，才能写出稳定、可扩展的 GUI 应用。