1. 为什么你的QThread跑起来，界面照样卡成PPT
先别急着往下看，你多半遇到过这种情况：界面上有个“开始处理”按钮，点击之后要解析一个几百兆的文件，或者对一批图片做缩放。最开始图省事，直接把解析代码写在按钮的槽函数里，结果点完按钮窗口立刻无响应，鼠标转圈，拖都拖不动。后来听人说“要用多线程”，就把那堆耗时逻辑挪进了QThread的子类里，重写个run()，然后start()，结果一跑——要么界面确实不卡了，但要么状态栏里的进度值死活不刷新，要么程序时不时就崩一下，要么退出的时候直接弹“QThread: Destroyed while thread is still running”。
这套路我太熟了，身边好几个同事都在这上面栽过跟头。网上关于Qt多线程的帖子不少，但大多数是把API摆一遍，真正能回答“为什么我照着写还是崩”的少。这篇我打算把QThread、工作对象（Worker）、线程间通信这三件事从头到尾捋一遍，代码给到能直接复制进工程的水平，然后把那些隐藏的坑一个个指出来。
先说结论：QThread本身并不是你真正干活的承担者。你要跑的耗时逻辑，应该放在一个普通的QObject派生类的普通方法里，然后把这个对象通过moveToThread()交给一个QThread，再由信号槽驱动这个对象的普通方法去执行。这才是Qt官方推荐的范式，也是你在实际项目里能稳定复用的写法。这篇文章适合谁？已经写过几行Qt代码、能看懂信号槽，但一碰多线程就头疼的开发者。看完之后你应该能从“知其然”到“知其所以然”。
这段子我先说清楚，别指望着QThread能够提供并行计算能力。多线程解决的不是计算快慢，而是响应流畅度。你解析大文件总共要花10秒，开线程之后还是10秒，用户该等还得等，区别在于等待的时候窗口能正常拖动、进度条会动、用户可以点“取消”。这个认知不纠正，后面学啥都别扭。
2. 先从你最熟悉的两种写法讲起
2.1 你在网上搜到的最常见的继承法
最常见的入门写法是继承QThread、重写run()。比如你有个类叫ParseThread，头文件里写：
class ParseThread : public QThread { Q_OBJECT public: ParseThread(QObject *parent = nullptr); protected: void run() override; };实现里把耗时逻辑怼进去：
void ParseThread::run() { QFile file("/path/to/huge/file"); // 逐块读取、解析、处理 for (int i = 0; i < 100; ++i) { // 模拟耗时 QThread::msleep(50); emit progress(i + 1); } }然后你在界面里这么用：
auto *thread = new ParseThread(this); connect(thread, &ParseThread::progress, this, &MainWindow::onProgress); thread->start();这段代码一编译就能跑，进度也能收到，看起来挺像回事。但问题在哪儿？最典型的一个是你往ParseThread里塞的成员变量越来越多，今天加一个文件名，明天加一个解析选项，后天又加一个结果容器，这个类逐渐从“一个跑任务的线程”长成“一个做过关杂活的神仙类”。时间一长，你发现很难写单元测试，因为一new就得真开线程，真开线程就得真处理文件。这是架构上的问题，不是马上崩的问题。
更重要的是：run()里如果用了信号槽来跟外界通信，信号槽的事件循环依赖关系需要额外小心处理。默认run()里不exec()，所以工作线程没有自己独立的事件循环，跨线程队列连接的消息就可能积压，表现为“有时候能收到，有时候收不到”。你说这不科学？其实科学，只是坑。后面我会专门讲事件循环这部分。
2.2 继承法为什么会让人越用越难受
我给个形象的比喻。你把房子装修的活儿交给了一个装修队，结果你给装修队头儿打电话说“顺便帮我把楼下的快递取了”“再帮我看看水表读数”，装修队头儿一方面要指挥工人干活，一方面又要听你派的零碎任务，时间一长指挥链全乱套了。继承QThread的本质就是让线程对象既当管理者又当劳动力，而且线程对象的生命周期归属在主线程这边，你没法轻易把它拨给别的线程。
再往深处说：QThread对象本身是活在创建它的线程里的，哪怕start()之后run()确实跑在另一个线程，你作为主线程依然可以随时访问这个QThread对象的成员函数和属性。这意味着什么？意味着如果你在ParseThread里加了一堆数据成员，主线程和工作线程理论上都可以触碰它们。数据竞争就这么悄无声息地来了。今天跑得欢，明天换了台多核机器就随机崩溃。
2.3 让我们换个姿势：工作对象 + moveToThread
既然继承法隐患这么多，那正统的路子长什么样？真正推荐的做法，是把耗时逻辑从“线程”里剥离出来，装进一个纯纯的QObject“工作对象”里，再把工作对象move到线程中去。这个工作对象只关心业务处理，它不知道“线程”这个概念，跟界面层的耦合降到了最低。
我用一个通用的写法来演示，你完全可以照抄：
class Worker : public QObject { Q_OBJECT public: explicit Worker(QObject *parent = nullptr); public slots: void doWork(const QString &filePath); signals: void progress(int percent); void finished(const QString &result); };实现里就不用管线程了，只管干自己的活：
void Worker::doWork(const QString &filePath) { // 模拟解析一个大文件 for (int i = 0; i <= 100; i += 10) { QThread::msleep(200); // 模拟耗时 emit progress(i); } emit finished("done: " + filePath); }界面侧怎么接？关键就靠moveToThread：
// 这里的thread是成员变量 m_thread = new QThread(this); m_worker = new Worker; // 注意：不要传this，不要给它设置父对象 m_worker->moveToThread(m_thread); connect(m_thread, &QThread::finished, m_worker, &QObject::deleteLater); connect(this, &MainWindow::startTask, m_worker, &Worker::doWork); connect(m_worker, &Worker::progress, this, &MainWindow::updateProgress); connect(m_worker, &Worker::finished, this, &MainWindow::handleResult); m_thread->start();然后你按钮的槽里只要emit那个startTask信号，Worker::doWork就会自动跑到工作线程里去执行。这里最关键的一点是：触发doWork的信号，发射者所在的线程是谁？如果发射者是主线程（按钮点击在主线程），那么Qt的AutoConnection会结合实际发送信号与接收者所处线程自动选择队列连接，于是槽函数doWork就被扔进了Worker所在线程的事件循环里，由工作线程去执行。
你仔细观察会发现，整个调用链里没有直接去操作线程的任何API，从界面到业务、再到线程的分发，全部通过信号槽连接完成。这就是它跟继承法最大的区别。
3. 线程间通信：信号槽的跨线程秘密
3.1 三种连接方式背后的线程判断逻辑
大多数人只知道connect里能传Qt::DirectConnection、Qt::QueuedConnection和Qt::AutoConnection，但没细想过背后判断的依据。我直接给你讲透：connect的时候，信号的发射者是哪个对象、接收者是哪个对象，各自动态地查一下它们所属的线程（通过QObject::thread()），然后比较是否同一个线程。同一个线程里直接调槽函数，这叫直接连接；不同线程的时候，把槽函数调用打包成一个事件丢进接收者的线程事件循环，这叫队列连接。
队列连接下发射信号时，信号参数会被复制进事件对象，等槽函数真正执行时再解包出来。所以它在设计上天然适合跨线程传值，但代价是参数必须是可拷贝的、有元类型信息的。如果你传一个自定义结构体，就得先qRegisterMetaType<T>()，否则Qt在编译期根本不知道你的类型，一运行就给你甩“Unknown type”。
AutoConnection默认行为：发射者线程跟接收者线程相同用Direct，不同用Queued。前提是接收者当前有活的事件循环在工作，队列里的槽函数才会被处理。如果接收者的线程退出或者压根没跑事件循环，跨线程信号就是石沉大海。这一点直接回答了很多人“为什么我信号发了线程里没收到”的疑问——十有八九是Worker所在线程没跑exec()，或者线程被误解了。
3.2 自定义类型跨线程传递：不注册的代价
说到自定义类型，我来一个实际例子。你在工作线程里处理完一批数据，得到一个结论：
struct ParseResult { int code; QString message; QList<QPair<int, int>> ranges; }; Q_DECLARE_METATYPE(ParseResult)然后Worker的信号是：
void parseDone(const ParseResult &result);如果你不调用qRegisterMetaType<ParseResult>("ParseResult")，在使用这个信号做跨线程连接时，程序大概率会当场警告：
QObject::connect: Cannot queue arguments of type 'ParseResult'为什么会这样？因为队列连接要把这个参数包进一个事件里，需要动态获取ParseResult的元类型信息。万一Qt不知道这类型怎么拷贝、怎么析构，它就拒绝工作。注册一下，在main函数里或者任何connect之前调用一次：
qRegisterMetaType<ParseResult>("ParseResult");这个动作就是在告诉Qt：这玩意儿我知道怎么拷贝，你把它当作一个合法的可传递类型。
3.3 队列连接里传指针和引用的陷阱
这是最容易让人迷糊的地方。如果队列连接里信号参数是const QString &这样的引用类型，因为信号槽的参数会被拷贝到事件对象里，所以引用就会被降级为对拷贝值的引用，安全。但如果你传的是裸指针QWidget*或者自定义类的指针MyData*，拷贝的只是指针本身，指针指向的对象生命周期不会被事件循环管理。什么意思？举个例子：你在Worker里new了一个对象，然后在工作线程里emit出一个携带这个对象指针的信号，主线程的槽收到了这个指针。此时如果Worker线程已经把那块对象销毁了，主线程再去访问，就变成悬垂指针，就是随机的crashes或者读出来的全是垃圾数据。
一个稳妥的做法是：跨线程不要传裸指针，要么传值（确保可拷贝），要么传Qt的智能指针比如QSharedPointer，让它在信号包拷贝的时候增加引用计数、保持存活。我自己的习惯是：数据量不大直接传值；数据结构复杂就传QSharedPointer<const T>。不要在跨线程信号里干传裸指针的蠢事，我是吃过这个亏的。
3.4 跨线程修改界面：该谁动手就谁动手
按照Qt的铁律，QWidget及其子类只能在创建它的主线程里访问。很多人犯的错误是Worker里包含一个QLabel*的成员，活干完了直接去setText()。这在某些情况下不会马上崩，但它是一个未定义行为，因为Qt的GUI模块不是线程安全的，两个线程同时对同一控件操作，轻则绘制错乱，重则直接崩溃。有个经典错误叫“QObject::setParent: Cannot set parent, new parent is in a different thread”，就是跨线程操作对象父子关系导致的。
正确姿势是：Worker根本不知道界面上有什么控件。它只负责emit信号，界面层自己决定要不要更新进度条、要不要弹结果框。保持这个原则，你的代码边界会清晰很多。
4. 一个能直接抄的完整实战：带进度上报的文件复制器
4.1 项目需求拆解与代码骨架
纸上谈兵半天，不如来一个完整的例子。我拿“大文件复制并实时显示进度”这个场景，把整个模块的代码按标准范式组装一遍。这个小项目麻雀虽小，五脏俱全，线程创建、工作对象、进度上报、结果回传、安全退出都被覆盖了。
先看Worker头文件：
#ifndef FILECOPYWORKER_H #define FILECOPYWORKER_H #include <QObject> #include <QString> class FileCopyWorker : public QObject { Q_OBJECT public: explicit FileCopyWorker(QObject *parent = nullptr); public slots: void copyFile(const QString &srcPath, const QString &dstPath); signals: void progress(int percent, qint64 bytesCopied, qint64 totalBytes); void copyFinished(bool success, const QString &message); void errorOccurred(const QString &errorString); }; #endif // FILECOPYWORKER_H实现中不会出现任何界面元素，就是纯粹的干活：
#include "FileCopyWorker.h" #include <QFile> #include <QFileInfo> #include <QDebug> FileCopyWorker::FileCopyWorker(QObject *parent) : QObject(parent) { } void FileCopyWorker::copyFile(const QString &srcPath, const QString &dstPath) { QFile src(srcPath); QFile dst(dstPath); if (!src.open(QIODevice::ReadOnly)) { emit errorOccurred("无法打开源文件: " + src.errorString()); return; } const qint64 totalBytes = src.size(); if (totalBytes == 0) { emit errorOccurred("源文件为空"); return; } if (!dst.open(QIODevice::WriteOnly | QIODevice::Truncate)) { emit errorOccurred("无法打开目标文件: " + dst.errorString()); return; } const qint64 bufferSize = 1024 * 1024; // 1MB char buffer[bufferSize]; qint64 bytesCopied = 0; while (!src.atEnd()) { qint64 readBytes = src.read(buffer, bufferSize); if (readBytes <= 0) { emit errorOccurred("读取文件失败"); return; } dst.write(buffer, readBytes); bytesCopied += readBytes; int percent = static_cast<int>(bytesCopied * 100 / totalBytes); emit progress(percent, bytesCopied, totalBytes); } dst.close(); src.close(); emit copyFinished(true, "复制完成"); }4.2 界面层如何组装线程与Worker
界面类一般是MainWindow，头文件部分：
class MainWindow : public QMainWindow { Q_OBJECT public: explicit MainWindow(QWidget *parent = nullptr); ~MainWindow() override; private slots: void onStartButtonClicked(); void onProgressUpdated(int percent, qint64 bytesCopied, qint64 totalBytes); void onCopyFinished(bool success, const QString &message); private: QThread m_thread; // 成员变量，确保窗口销毁时线程对象还在 FileCopyWorker *m_worker = nullptr; QPushButton *m_startButton = nullptr; QProgressBar *m_progressBar = nullptr; QLabel *m_statusLabel = nullptr; };实现部分，重点看构造函数里的组装：
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) { // 创建控件略…… m_worker = new FileCopyWorker; // 无父对象 m_worker->moveToThread(&m_thread); // 线程结束时清理worker connect(&m_thread, &QThread::finished, m_worker, &QObject::deleteLater); // 主界面的按钮点击触发线程里的工作 connect(m_startButton, &QPushButton::clicked, this, [this]() { QString src = QFileDialog::getOpenFileName(this, "选择源文件"); if (!src.isEmpty()) { QString dst = QFileDialog::getSaveFileName(this, "选择目标位置"); if (!dst.isEmpty()) { emit startCopy(src, dst); } } }); // 关键一步：startCopy信号携带路径参数，直接连到Worker::copyFile connect(this, &MainWindow::startCopy, m_worker, &FileCopyWorker::copyFile); // 进度和结果回传 connect(m_worker, &FileCopyWorker::progress, this, &MainWindow::onProgressUpdated); connect(m_worker, &FileCopyWorker::copyFinished, this, &MainWindow::onCopyFinished); m_thread.start(); }等一下，我刚才用了一个startCopy自定义信号，需要在MainWindow的类声明里加上：
signals: void startCopy(const QString &srcPath, const QString &dstPath);这样按钮点击后emit的信号才会进入事件系统，才可能被队列调度到Worker线程里去。注意这里不是直接把clicked连到copyFile，因为clicked()不带参数，所以用一个lambda中转，再用自产信号去触发Worker。
为什么不在lambda里直接调用m_worker->copyFile(src, dst)？如果你直接这样调用，由于当前正在主线程，copyFile就会同步跑在主线程里，根本没进工作线程。你emit一个信号，让Qt来根据线程情况决定如何调用，这才是跨线程调用的王道。这一个理念值很多实践。
4.3 进度与结果的跨线程回传
Worker跑在后台线程时，发出的progress信号会自动进入主线程的事件循环：
void MainWindow::onProgressUpdated(int percent, qint64 bytesCopied, qint64 totalBytes) { m_progressBar->setValue(percent); double mbCopied = bytesCopied / (1024.0 * 1024.0); double mbTotal = totalBytes / (1024.0 * 1024.0); m_statusLabel->setText(QString("%1 MB / %2 MB").arg(mbCopied, 0, 'f', 1) .arg(mbTotal, 0, 'f', 1)); }结果处理：
void MainWindow::onCopyFinished(bool success, const QString &message) { m_progressBar->setValue(success ? 100 : 0); m_statusLabel->setText(message); m_startButton->setEnabled(true); }这套连接为什么能work？因为信号是从Worker线程发射的，接收者MainWindow在主线程，AutoConnection自动采用队列连接，槽函数的执行真正回到了GUI线程，界面更新才是合法的。这不是Qt在背后帮你做了什么魔法，而是它老老实实检查了两个对象各自的thread()归属，然后走了一遍跨线程事件派发。
4.4 安全退出的正确姿势
这是重头戏。窗口关闭时如果工作线程还在跑会怎样？你有很大概率在控制台看到这句话：
QThread: Destroyed while thread is still running更糟糕的是直接崩溃。正确的关闭顺序是：先停止Worker的活，让事件循环退出，最后销毁线程对象。我提供一个稳妥的析构模板：
MainWindow::~MainWindow() { if (m_thread.isRunning()) { // 1. 请求工作线程退出事件循环 m_thread.quit(); // 2. 等待线程真正退出，最多等5秒 if (!m_thread.wait(5000)) { // 3. 如果还在跑，强制终止（慎用） m_thread.terminate(); m_thread.wait(); } } }这里有一个关键细节：quit()只是通知QThread内部的事件循环退出，如果Worker的copyFile还在一个耗时循环里没返回，事件循环根本退不出去，wait就直接超时。针对这种情况，更好的解法是给Worker加一个“可取消”状态。我在实际项目里一般用原子布尔变量：
// Worker类里新增 public: void cancelRequested() { m_cancelled.store(true); } private: std::atomic_bool m_cancelled{false}; void FileCopyWorker::copyFile(const QString &srcPath, const QString &dstPath) { // 循环里每次检查 while (!src.atEnd()) { if (m_cancelled.load()) { emit copyFinished(false, "已取消"); return; } // 正常复制 } }然后界面析构时先请求取消，而不是直接quit：
if (m_worker) { m_worker->cancelRequested(); } m_thread.quit(); m_thread.wait(5000);这个模式我用了很久，非常可靠。
5. 高频率翻车现场：这些问题你应该全部见过
5.1 为什么我的信号发了，槽函数却不执行
这是新手第一大问。排查思路很简单，按下面列表逐条比对：
- 接收者所在线程没有运行事件循环。QThread::run()内默认会执行
exec()启动事件循环，但如果你重写了run()且没有调用exec()，那线程里的事件循环就是死的。跨线程队列连接过去的消息没人处理。 - Worker对象在线程启动前没有moveToThread成功。检查一下
worker->thread()到底返回哪个线程，最好在启动后打印验证。 - 信号和槽的签名不匹配，但编译器可能不报错（特别是老式connect写法），只会在运行时给出警告。新代码建议一律使用新式语法+lambda。
- 自定义参数类型忘记注册，connect的时候报“Cannot queue arguments”。
- 函数的访问权限或信号槽声明遗漏了
Q_OBJECT，导致moc没有生成对应元数据。
5.2 窗口关闭时莫名其妙崩溃，多半是顺序问题
我见过太多人这么干：MainWindow的析构函数里直接delete m_thread;，结果线程还没停，Qt在堆栈深出检测到线程对象被销毁而线程仍在运行，直接abort。正解就是上文给的quit() + wait() + 必要时terminate()的口径。另外要注意：Worker如果用deleteLater清理，必须确保在QThread::finished信号里连接好，并且事件循环能够处理这个延迟删除事件，否则你的Worker会一直挂着。
5.3 定时器、第三方库、原生C++线程混进来，怎么处理
如果你在Worker里用了QTimer，注意：定时器依赖事件循环，moveToThread之后的Worker没有特别准备也能正常用QTimer，前提是QThread的run()是默认事件循环版本。反过来，如果你在线程里用sleep()或者阻塞操作阻塞了事件循环，那么所有队列连接和定时器全部停摆。这个坑极隐蔽，因为看起来只是“延迟了一下”。
跟第三方库打交道是另一个大坑。有些库不是线程安全的，但它们自己内部开了原生线程，你把这些库对象move到Qt线程也没用，因为库的回调不在你的Qt线程事件循环里。我之前做一个采集程序，第三方采集SDK通过回调函数给数据，我在回调里直接emit Qt信号，结果时好时坏。最后是用一个线程安全队列收数据，再由Worker里的QTimer定时去取，才彻底稳定下来。所以记住：Qt的线程模型管不住原生线程，跨库线程边界时一定要自己做同步。
5.4 信号槽传参里潜藏的“隐式拷贝”性能陷阱
如果你在跨线程信号里传一个大容器，比如QList<QByteArray>，里面装了上百兆数据，队列连接会把容器做一次深拷贝。你想省这个拷贝，可以传QSharedPointer<const T>或者QByteArray本身引用计数版本。但要记住：不要为了省事把数据变成全局变量然后传指针，线程安全防线被击穿的代价比多拷贝几毫秒高得多。
6. 线程数量、优先级与任务调度的工程取舍
多线程并不是越多越好。很多人看到Qt可以开线程，就恨不得每个模块都开一个，结果线程上下文切换开销比干活本身还大。我建议你遵循几条简单的实践经验：
- 任务与线程之间的关系是一对多。不要为每个小任务单独new一个QThread，用完就扔，这样频繁创建销毁线程会浪费系统资源。正确做法是常驻一个工作线程，接收到任务信号就干活，干完继续等待。
- 需要并行处理一批独立任务时，考虑使用QtConcurrent::run或者QThreadPool，而不是手动管理一堆QThread。它们能复用线程池里的线程，不需要你操心生命周期。
- 优先级只在真正需要的时候调整，默认优先级通常够用。调高了可能抢GUI线程的CPU时间，反而让界面更卡；调低了任务完成太慢，用户又觉得没反应。
还有一种场景：你需要同时跑多个不相关的耗时任务。有的人会创建多个Worker，分别move到不同线程。我试过，跨线程信号连接变得复杂，而且内存管理容易出漏。我的建议是把任务队列串行化，一个Worker用任务列表加定时器轮询，虽然任务排着队，但是不会卡界面，调试也容易得多。真需要并行时，再用QThreadPool和QtConcurrent去拆分。
7. 进阶：任务管理器模式与线程安全的MVC改革
如果你的业务达到一定复杂度，比如“界面上有N种任务，每个任务有独立的生命周期”，这时候还在MainWindow里手动维护Worker和Thread的配对就不够了。我自己写过一个简单任务管理器，核心思想是一个QThread固定搭配若干个Worker，按任务类型分发：
class TaskManager : public QObject { Q_OBJECT public: explicit TaskManager(QObject *parent = nullptr); void start(); void stop(); template<typename TaskWorker> TaskWorker *createWorker(); private: QThread m_thread; QList<QObject*> m_workers; };然后createWorker时统一做moveToThread和finished的deleteLater连接。界面只会跟TaskManager打交道，不直接碰Worker细节。这样做的好处是你把“线程”这个概念完全包在了任务管理器内部，同事们接你的项目时不需要在多线程细节里做心理挣扎。
再延伸一下，跨线程信号槽与Qt的MVVM模式结合时，你可以在ViewModel层使用QObject，专门暴露可绑定的属性和命令。后台逻辑全部挂在Worker上，界面层只订阅ViewModel的变化。这个架构的好处是界面和业务天然隔离，跨线程通信全部收敛在边界处。不过MVVM在Qt社区算小众，很多项目直接Widget堆到底，我也不想过度安利；但如果你是做一个大型桌面应用，从没有架构演进到有点架构，这个方向值得琢磨。
8. 我踩过的最深的坑：QThread竟然是这么理解的
这里聊一点容易被忽略的本质。很多人以为start()一调用，run()就立刻在新的原生线程里跑了；也确实如此。但QThread对象本身并不等于那个线程，它只是一个“控制器”对象，你在主线程里new QThread，它的thread()属性就指向主线程。只有它管理的那个原生线程是新的。这导致一个陷阱：你在QThread的子类里定义的信号槽、成员变量，它们的归属到底是主线程还是新线程？答案是：QThread对象的信号槽连接，默认仍然视为主线程里的对象，因为QObject::thread()返回的是创建它的线程。只有那些被moveToThread真正搬过去的Worker，槽函数才真正在新线程里执行。
这个认知一旦建立，你对网上很多“如何停线程”“如何传参”的讨论就能一针见血地看出问题，不再被各种google来的代码带偏。
信号槽是Qt的灵魂，跨线程信号槽则是对这个灵魂的终极考验。多线程代码要写得稳，核心在于清楚每个对象的归属线程和每个连接的类型，而不是写出一堆看起来能跑的窍门。
9. 关于调试与性能验证的一点建议
// 一个不起眼但是很实用的小工具 qDebug() << "main thread: " << QThread::currentThread() << " worker thread: " << m_worker->thread();每当你怀疑“某个槽函数到底跑在哪个线程”，就在这里打一行日志，打印QThread::currentThread()，立刻水落石出。我每天都在用这招来验证自己的推论。
性能验证方面也有官方工具可以用。界面不卡不等于性能达标，你可以在任务循环里记录时间戳，或者用Qt的QElapsedTimer测量每段任务的耗时占比。真实的瓶颈往往是文件IO和第三方算法，不是线程切换。盲目多开线程只会在任务结束后让一堆线程在那里空转等待，白白吃掉系统资源。
给一个最后检查清单，每次写多线程代码之前过一遍：
- Worker没有父对象，且已moveToThread到目标线程
- 线程启动信号、Worker的deleteLater连接正确
- 跨线程传递的自定义类型做了注册
- 窗口析构按顺序quit、wait，处理了取消逻辑
- 没有跨线程直接操作QWidget
- 所有跨线程数据共享都加了锁或用了原子类型
这套清单帮我避开了绝大部分的线上崩溃。有个老项目里面既有QThread又有Windows原生线程，还有第三方SDK回调，我花了大半个星期把它的线程关系理清后全部改造成统一范式，从那以后这个模块再没出现过诡异的崩溃。
花点时间把你现有的QThread代码审视一遍，哪怕只是按这一篇文章里的模式重构一个小地方，也能体会到整体复杂度的下降。
