Qt多线程核心原则是GUI操作必须在主线程，跨线程直接调用QWidget成员函数会导致崩溃；推荐使用QObject+moveToThread模式分离逻辑与线程管理，而非继承QThread重写run()。
Qt 多线程不是“开了线程就能随便操作界面”，核心原则只有一条：QThread 对象本身属于创建它的线程（通常是主线程），只有 run() 里的代码才真正在新线程里跑；所有 GUI 操作必须在主线程，跨线程直接调用 QWidget 成员函数会崩溃或未定义行为。
为什么继承 QThread 并重写 run() 容易出错
很多人照着示例写个 MyThread : public QThread，把耗时逻辑塞进 run()，再加个 emit signal 更新 UI，看似能跑，但隐患密集：
-
MyThread的构造函数、成员变量初始化、信号连接等全在主线程执行，若在这些地方访问共享数据（比如一个QList），没加锁就可能被run()同时读写 - 如果在
run()里忘了调用QThread::exec()，就无法接收信号（比如外部想发停止指令） -
QObject::deleteLater()在子线程调用无效，手动delete又容易提前释放导致 crash - 线程对象和工作逻辑耦合太紧，复用性差，测试困难
推荐方式：QObject + moveToThread
这才是 Qt 官方从 Qt 4.8 起就明确推荐的模式，它把“线程管理”和“业务逻辑”彻底分离：
- 写一个普通
QObject子类（比如Worker），只管干活，不碰线程生命周期 - 用
QThread*对象管理线程，调用worker->moveToThread(thread)把它移过去 - 靠信号槽自动排队：
connect(worker, &Worker::resultReady, this, &MainWindow::onResult, Qt::QueuedConnection)—— 这种连接类型让槽函数一定在接收方所属线程（主线程）执行 - 线程退出时，用
connect(thread, &QThread::finished, worker, &QObject::deleteLater)，安全释放
关键点：moveToThread() 必须在 thread->start() 之前调用，且 worker 不能是栈对象（得 new 出来）。
QThread::currentThread() 和 QThread::currentThreadId() 到底该看哪个
调试时经常要确认某段代码是否真在线程里运行，别只看指针地址：
-
QThread::currentThread()返回当前执行代码所在线程的QThread*对象指针，可用于判断是否等于你创建的QThread实例（但注意：主线程返回的是全局QThread对象，不是nullptr） -
QThread::currentThreadId()返回 OS 级线程 ID（qint64），更底层、更稳定，适合日志打点或和系统工具（如ps -T）对照 - 常见误判：在
Worker构造函数里打印QThread::currentThread()，结果还是主线程指针——因为构造发生在主线程，moveToThread()是之后才生效的
线程退出和资源清理最容易漏的三件事
不是调了 thread->quit() 就万事大吉：
- 如果
Worker里用了QTimer或正在处理事件循环，必须先显式timer->stop()或发停止信号并等待响应，否则thread->quit()会卡住 -
thread->wait()应该只在主线程需要同步等待线程结束时才用（比如程序退出前），日常交互中应靠finished()信号驱动清理 - 如果
Worker持有文件句柄、网络 socket 或第三方库资源，必须在~Worker()析构函数里释放，而析构时机取决于deleteLater()是否被正确触发——这要求worker的父对象为空，且信号连接完整
真正难的从来不是“怎么开线程”，而是“怎么确保线程干净退出、资源不泄漏、信号不丢、UI 不卡死”。每个 moveToThread 调用背后，都得对对象生命周期、事件循环、连接类型心里有数。
