Qt多线程入门：从界面卡死到线程方案选型与实战-平芜编程栈

写Qt多线程最怕什么？绝大多数小伙伴第一次遇到“界面假死”的时候，都以为是自己代码写崩了，其实是把耗时任务直接丢到了GUI线程里跑。我这个系列打算把Qt多线程的使用从头捋一遍，今天先讲最基础也最核心的东西——线程到底是什么、Qt提供了哪些多线程方案、不同方案之间怎么选、每种方案常用的代码怎么写。内容不追求大而全，但保证每一段都是能把项目跑起来的关键点。

这个系列适合已经开始写Qt但一碰到耗时任务就头大的朋友，也适合刚接触C++并发编程、想搞明白QThread和std::thread到底哪个更好的开发者。读完这一篇，你至少能回答三个问题：界面卡死怎么解决、子线程里该不该动UI、QThread子类化和moveToThread到底该用哪个。

1. 内容整体设计与思路拆解

1.1 为什么必须给Qt引入多线程

一句话：GUI程序的主线程（也叫GUI线程）要同时干两件事——跑事件循环（处理鼠标、键盘、定时器、信号槽等）和执行你写的业务逻辑。当业务逻辑里有耗时操作，比如读大文件、请求网络接口、做图片处理、批量查数据库，主线程就被占住了，事件循环没法及时处理窗口消息，表现出来就是窗口拖不动、按钮点不了、标题栏显示“未响应”。

多线程就是把这个局面拆开：把耗时任务放到工作线程去跑，主线程专心维护界面。用户那边看到的是窗口一直流畅，后台在悄悄干活，活干完了用信号通知界面刷新。这就是QThread这类工具存在的价值。

线程本身是操作系统提供的执行单元，一个进程里可以同时跑多个线程，它们共用进程的内存空间，但各有各的执行栈。Qt在原生线程库之上封装了自己的抽象——QThread，通过它你可以用Qt的风格管理线程生命周期、信号槽连接，甚至跨线程传递自定义类型。理解Qt多线程，第一步就是抛掉“线程只是算得更快”的误解，它是程序架构层面的问题。

1.2 Qt多线程方案的选型对比

Qt文档里其实提供了好几套多线程工具，我实际用得最多的有三类：QThread、QRunnable配合QThreadPool、以及QtConcurrent。这三者不是互相替代的关系，而是分别解决不同层次的需求，我把对比整理成了表格，方便一眼看清适用场景。

方案	核心思路	适用场景	复杂度
QThread（子类化）	继承QThread重写run()，把耗时逻辑放进去	简单耗时操作、一次性任务，比如文件导出	较低
QThread + moveToThread	把工作对象移动到子线程，通过信号槽驱动	需要长期驻留、持续接收指令的后台线程	中等
QRunnable + QThreadPool	任务对象塞进线程池，由线程池统一调度复用	高频短任务、并发批量任务，比如线程池并发下载	中等
QtConcurrent	面向函数的并发API，一行代码启动异步任务	纯计算、并行遍历、结果收集，不需要复杂事件交互	较低

初学者最容易犯的错，是干什么都用QThread子类化。遇到一个千变万化的任务体系，比如在线程里要反复接收UI发来的指令、执行不同操作、中途可能还要取消任务，子类化QThread就会变得特别别扭，因为run()只能执行一遍，没法高效接收外部信号。这时候moveToThread才是正解。

如果只是想让某个耗时的函数在后台跑一把，完全没必要动QThread，QtConcurrent::run一行代码就能解决，写多了反而是过度设计。选型的关键逻辑就一句话：任务是一次性的还是常驻的？交互是单向的还是双向的？任务频率是高还是低？把这四个问题答完，方案基本就锁定了一大半。

1.3 线程安全与事件循环的关系

聊多线程必谈线程安全。Qt的很大一部分类都有“线程亲和性”限制，典型的比如QWidget、QTimer、QThread本身，它们默认归属于创建它的线程——也就是GUI线程。如果你在子线程里直接操作一个主线程创建的QLabel，轻则界面不刷新，重则直接崩溃。

QThread之所以能和信号槽配合实现跨线程通信，是因为它内部实现了一套事件循环机制。moveToThread之后，工作对象的事件处理会被投递到目标线程的事件队列中，由目标线程的事件循环去执行。这个设计本质上是把线程间数据交换变成了事件投递，用队列加锁的方式天然规避了大量并发写的问题。理解了这个原理，你就明白为什么“子线程里不要直接改UI”是一条铁律——不是因为Qt禁止，而是UI控件的操作本来就不是线程安全的，跨线程访问等于竞态条件。

当然，线程安全也意味着你在线程里访问同一个共享容器（比如QMap、QList）时要自行加锁，或者用Qt提供的线程安全类，比如QReadWriteLock、QMutex，甚至换用消息传递的模式。很多新手把信号槽当成“万能线程同步工具”，跨线程传复杂对象的时候没自定义register类型，结果编译不过或者运行期警告，这些细节我在后面的小节里会逐一展开。

2. 核心细节解析与实操要点

2.1 QThread子类化：最直观的入门方式

先给出一个最典型的子类化写法，我会把每一步都拆开解释。

class WorkerThread : public QThread { Q_OBJECT protected: void run() override { // 这里执行耗时操作 for (int i = 0; i < 100; ++i) { msleep(50); emit progress(i + 1); } emit finished(); } signals: void progress(int percent); void finished(); };

这个类继承QThread，重写run()，run()就是子线程的入口点。调用start()之后，run()会在新线程中执行。在run()里发信号没问题，因为信号不依赖线程，connect到GUI线程的槽就会被自动排队处理，这正是Qt跨线程通信的核心。

但子类化QThread有个天然的坑：run()执行完，线程对象还在，但底层线程已经退出。如果你想再次start()复用同一个对象，Qt会警告“QThread: Destroyed while thread is still running”或者根本无法再次启动。所以这种写法更适合“发起就跑，跑完就完”的任务模型。比如导出Excel报表、生成缩略图、执行一次重型计算。

实际开发中我建议子类化的时候，把自定义信号放得越细越好，例如progress、finished、errorOccurred，这样调用方可以完整感知线程状态。再说一句题外话：run()里如果涉及Qt容器，尽量用局部变量，跨线程传大对象时优先用Qt的隐式共享机制，避免深拷贝阻塞线程。

2.2 moveToThread：事件驱动的常驻线程

一个更工程化、也更能发挥Qt信号槽优势的做法，是把任务类定义成QObject，然后通过moveToThread把对象塞进线程。萌新第一次看到这段代码可能会绕晕，我拆开讲。

class Worker : public QObject { Q_OBJECT public slots: void doWork(const QString &parameter) { // 子线程中运行的耗时逻辑 for (int i = 0; i < 100; ++i) { QThread::msleep(30); emit progress(i + 1); } emit workDone(); } signals: void progress(int percent); void workDone(); }; // 启动线程的代码 Worker *worker = new Worker; // 注意：先创建，此时还在主线程 QThread *thread = new QThread; // 线程对象本身在主线程 worker->moveToThread(thread); // 关键：改变对象亲和性 connect(thread, &QThread::started, worker, &Worker::doWork); connect(worker, &Worker::workDone, thread, &QThread::quit); connect(worker, &Worker::workDone, worker, &Worker::deleteLater); connect(thread, &QThread::finished, thread, &QThread::deleteLater); thread->start();

这套组合拳为什么是官方推荐的？核心在于它让“工作对象”和“线程对象”解耦。线程对象QThread可以被反复start，Worker对象可以在线程里接收任意信号、执行任意槽函数。也就是说线程是常驻的，任务是事件驱动的。比如一个后台处理线程，它可以接收“处理文件A”“处理文件B”“取消任务”等不同指令。

这里有几个细节我得特别提醒：

new Worker时它还在主线程，一旦moveToThread，它的事件处理就全部切换到了子线程执行。所以构造函数里的初始化尽量放moveToThread之前，避免在错误的线程里初始化。
doWork槽函数如果带参数，外部connect时要用Qt::QueuedConnection或默认自动选择。跨线程信号槽默认自动使用队列连接，因此不会直接在发送者线程里同步执行。
在线程退出前，一定要保证Worker的所有操作已经结束，否则用deleteLater清理时可能踩到“对象还被事件循环占用”的坑。

我自己用它做了一个后台下载管理器，线程常驻，三个下载任务可以随时提交，中途还能取消，代码逻辑非常清晰。对比子类化QThread，这个方式写起来稍繁琐一点，但应对复杂业务场景的扩展性要好太多。

2.3 QtConcurrent与线程池：函数级并发的最佳实践

当你连QThread都不想要，只希望把一个函数丢到后台跑，QtConcurrent是首选。它这套API给我的感觉就像C++的std::async，但和Qt的信号槽集成得更自然。

#include <QtConcurrent/QtConcurrent> // 启动一个后台任务 QFuture<int> future = QtConcurrent::run([]() { int sum = 0; for (int i = 0; i < 10000; ++i) { sum += i; } return sum; }); // 如果需要在任务完成后刷新界面，使用QFutureWatcher QFutureWatcher<int> *watcher = new QFutureWatcher<int>(this); connect(watcher, &QFutureWatcher<int>::finished, this, [=]() { int result = watcher->result(); // 更新UI }); watcher->setFuture(future);

QtConcurrent::run支持成员函数、lambda、函数对象，还会自动利用全局线程池。默认线程池的大小是当前CPU核心数，这意味着你并发跑多个任务时，系统会合理分配线程，不会因为手动new线程导致泛滥。

QtConcurrent还提供map、filter等函数式API，特别适合数据并行处理，比如对一个大集合的每个元素做同样转换：

QList<int> list; // 填充数据... QFuture<void> future = QtConcurrent::map(list, [](int &value) { value = value * 2; }); future.waitForFinished();

这个写法把线程调度的细节完全屏蔽了，你只需要告诉它“对每个元素做什么”。对于计算密集型的批量任务，代码会异常简洁。

不过QtConcurrent也不是万能的。第一，它面向一次性任务，不适合需要长期运行的交互式后台线程；第二，你没办法直接取消一个QFuture，虽然可以配合QFutureWatcher做取消标记，但任务本身如果卡在阻塞调用里是停不下来的。第三，如果函数里耗时操作需要持续反馈进度，用QtConcurrent会麻烦一些，得额外用QProgressDialog或自定义信号来定期报告。

2.4 进度上报：别在主线程刷UI

不管用哪种方案，后台任务都要考虑往界面上报进度。最基本的做法是自定义一个进度信号，比如percentChanged(int)，每完成一定比例发一次。注意信号别发太频繁，比如一个很紧的循环每循环一次发一次，那主线程光处理进度信号都能卡一顿。合理做法是每隔一段时间或者隔一定步数才发一次。

for (int i = 0; i < total; ++i) { // 耗时处理 if (i % 10 == 0) { emit progress(i * 100 / total); } }

还有一种常见需求是往日志区域打印输出，处理思路跟进度类似，通过信号把信息字符串传给主线程，主线程在appendPlainText。不要直接在线程里操作文本框，我曾经见过一个项目，子线程里直接调ui->textEdit->append，结果程序频繁崩溃，改成信号槽之后瞬间稳定。

如果你需要在线程里定时上报状态，而不是循环里主动发，可以用QTimer。但这里有个典型的坑——QTimer依赖事件循环，在子线程中使用时要确保该线程的事件循环正在运行（即调用了exec()），moveToThread的方式天然满足这个条件，而子类化QThread中如果run()里没有调用exec()，QTimer就不会触发。这是很多人在子线程里用QTimer发现槽函数一直不执行的原因。

3. 实操过程与核心环节实现

3.1 从界面假死到多线程改造：一个完整案例

我拿一个超级典型的例子来走一遍实操：一个按钮触发耗时计算并把结果显示到QLabel上。先用错误的单线程写法，再用多线程改造，顺便把进度显示也做出来。

项目结构如下：

MyThreadDemo/ ├── MyThreadDemo.pro ├── main.cpp ├── MainWindow.h ├── MainWindow.cpp ├── Worker.h └── Worker.cpp

先看“错误示范”，假设主窗口里有一个按钮onStartClicked，点击后执行一段会卡顿3秒的计算：

void MainWindow::onStartClicked() { // 计算1到100万的累加和，纯属模拟耗时 qint64 sum = 0; for (int i = 1; i <= 1000000; ++i) { sum += i; QThread::msleep(1); // 强行放慢速度，制造卡顿效果 } ui->labelResult->setText(QString("结果：%1").arg(sum)); }

这段代码的后果就是：点击按钮后窗口冻结，鼠标移动都困难，必须等循环跑完才能恢复。把这段计算挪到子线程，是大家都能想到的方案，重点是怎么把结果安全送回界面。

3.2 使用moveToThread改造并显示进度

在Worker类中定义工作槽和进度信号：

// Worker.h class Worker : public QObject { Q_OBJECT public: explicit Worker(QObject *parent = nullptr); public slots: void doHeavyWork(); signals: void progress(int percent); void resultReady(qint64 sum); }; // Worker.cpp void Worker::doHeavyWork() { qint64 sum = 0; const int total = 1000000; for (int i = 1; i <= total; ++i) { sum += i; QThread::msleep(1); if (i % 10000 == 0) { emit progress(i * 100 / total); } } emit resultReady(sum); }

MainWindow里这样接：

void MainWindow::onStartClicked() { // 先清理可能存在的旧线程 if (thread && thread->isRunning()) { return; } thread = new QThread(this); worker = new Worker; worker->moveToThread(thread); connect(thread, &QThread::started, worker, &Worker::doHeavyWork); connect(worker, &Worker::progress, this, &MainWindow::updateProgress); connect(worker, &Worker::resultReady, this, &MainWindow::showResult); connect(worker, &Worker::resultReady, thread, &QThread::quit); connect(worker, &Worker::resultReady, worker, &Worker::deleteLater); connect(thread, &QThread::finished, thread, &QThread::deleteLater); thread->start(); } void MainWindow::updateProgress(int percent) { ui->progressBar->setValue(percent); } void MainWindow::showResult(qint64 sum) { ui->labelResult->setText(QString("结果：%1").arg(sum)); }

这套流程跑起来，界面会非常流畅：按钮点击后立刻启动子线程，进度条逐步增加，最后结果回填。关键就是所有操作UI的代码都在MainWindow的槽函数里执行，子线程只负责算和发信号。

3.3 线程清理与生命周期管理的正确姿势

上面代码中我加了一堆deleteLater和quit的连接，这就是生命周期管理的关键。很多新手在线程退出时直接delete thread对象，结果程序崩溃。原因在于QThread对象如果还在运行，直接delete会导致“QThread: Destroyed while thread is still running”崩溃。

正确的清理逻辑是这样的：

任务完成后，通过workDone信号通知thread->quit()，让事件循环退出。
通过worker->deleteLater()清理工作对象，保证它在事件循环中安全删除。
通过thread::finished信号连接thread::deleteLater，让线程对象在底层线程结束后再删除。

如果窗口关闭时线程还在跑，应该在主窗口的closeEvent中主动请求线程停止：

void MainWindow::closeEvent(QCloseEvent *event) { if (thread && thread->isRunning()) { // 通知线程退出 thread->quit(); // 等待线程结束，最多等3秒 if (!thread->wait(3000)) { // 线程没反应，强制终止（不推荐但有时没办法） thread->terminate(); thread->wait(); } } QMainWindow::closeEvent(event); }

这里再补充一个经验：terminate()是危险动作，它会立即中止线程并在任意位置停止代码，极有可能导致资源泄漏或数据不一致。能用quit()+wait()就绝对不要用terminate()。如果线程里有阻塞调用导致quit()等不到，建议把阻塞操作改成非阻塞方式，或者用条件变量+超时机制优雅退出。

3.4 高并发场景：QThreadPool + QRunnable实战

再演示一个更适用于高频任务组合的场景。假设要批量生成100张缩略图，每张图都很小但数量大，为每张图单独开线程显然不明智，线程池是最好的方案。

class ThumbnailTask : public QRunnable { public: void run() override { QImage image = loadImage(m_filename); QImage thumb = image.scaled(160, 120, Qt::KeepAspectRatio, Qt::SmoothTransformation); saveThumbnail(thumb, m_outputPath); } QString m_filename; QString m_outputPath; }; // 使用 ThumbnailTask *task = new ThumbnailTask; task->setAutoDelete(true); // 默认就是true，线程池会自动delete任务对象 QThreadPool::globalInstance()->start(task);

这里QRunnable是轻量任务接口，QThreadPool负责管理线程复用。默认全局线程池的大小等于CPU核心数，所以100个任务不会同时开100个线程，而是排队执行。这也意味着你不需要关心线程创建销毁的开销。

QRunnable没有信号槽机制，所以如果你需要把执行结果传回UI，最简单的办法是让任务持有QObject指针，或者改用QtConcurrent::run加QFutureWatcher。我一般在简单的批量任务里用QtConcurrent，确实更省事。

比如上面缩略图的场景，用QtConcurrent::map组合lambda就可以一行搞定：

QList<QString> fileList = getAllImageFiles(); QFuture<void> future = QtConcurrent::map(fileList, [](QString &file) { QImage image(file); QImage thumb = image.scaled(160, 120, Qt::KeepAspectRatio, Qt::SmoothTransformation); thumb.save(file + "_thumb.jpg"); }); QFutureWatcher<void> *watcher = new QFutureWatcher<void>(this); connect(watcher, &QFutureWatcher<void>::finished, this, &MainWindow::onThumbnailsDone); watcher->setFuture(future);

这里唯一的坑就是：QFutureWatcher必须在主线程中创建，setFuture后会自动监视后台任务是否完成，完成后会发finished信号。如果直接在lambda里操作UI，还是会踩到线程不安全的坑，最好是发送一个自定义信号或者用watcher的回调。

3.5 线程间通信：自定类型的注册与传递

跨线程信号槽传自定义类型是另一个高发坑区。Qt的信号槽机制依赖元对象系统，如果参数是自定义类型，编译时可能有警告“Unable to handle unregistered datatype”。解决办法是调用qRegisterMetaType注册：

// 自定义结构体 struct TaskResult { int status; QString message; QByteArray data; }; Q_DECLARE_METATYPE(TaskResult) // 使用前注册，最好放在main函数里 qRegisterMetaType<TaskResult>("TaskResult");

如果类型只在信号槽里用，不参与Q_PROPERTY或者QVariant转换，也可以在connect之前注册一次就行。注册之后，跨线程传递时Qt才能正确地在事件队列中保存和复制参数。

实际项目里我还遇到过用QVector<自定义结构体>跨线程传递的，这种复合类型也要注册：

qRegisterMetaType<QVector<TaskResult>>("QVector<TaskResult>");

还有一个细节：跨线程信号槽默认队列连接，参数会拷贝一份放入事件队列。如果传的是体积很大的容器，性能会受影响。解决方案是传递共享指针或者索引，让子线程按索引去取数据，或者用Qt的隐式共享类比如QByteArray、QString、QImage，它们拷贝是浅拷贝，性能开销小得多。

4. 常见问题与排查技巧实录

4.1 线程结束后程序Crash：多半是生命周期问题

这是我在社区里看到最多的提问：“程序跑完线程就崩了”。排查思路非常固定——先看是不是在子线程里操作了UI，再看是不是直接delete了还在运行的QThread对象，最后看是不是忘记调用deleteLater。

我先给一个速查表，方便按顺序排查：

现象	大概率原因	解决办法
点击按钮后界面卡死	耗时任务跑在主线程里	把任务放入QThread或QtConcurrent
线程结束后程序崩溃	直接delete了QThread对象	使用thread->wait()后再delete，或者用deleteLater
界面偶尔崩溃、无规律	子线程直接操作了UI对象	改成信号槽方式，让主线程统一更新UI
子线程的槽不执行	线程没有事件循环	使用moveToThread并在run里调用exec()，或改用QThread::run驱动信号槽
编译警告unregistered datatype	自定义类型未注册	qRegisterMetaType注册类型

在调试阶段，可以用Qt自带的qDebug输出线程ID，确认槽函数到底在哪个线程执行：

qDebug() << "Current thread:" << QThread::currentThread();

如果你发现某个槽函数预期在子线程执行，却打印出主线程地址，说明连接方式或者对象亲和性出了问题。排查方式回看moveToThread有没有正确调用、connect时有没有手动指定Qt::DirectConnection。

4.2 子线程中使用QTimer失效：事件循环与线程的关系

之前简单提过，子线程里用QTimer不触发的根本原因是线程没有跑事件循环。QThread子类化时，run()默认只执行你写的代码就返回了，整个线程并没有进入exec()，那事件循环就是停的。moveToThread方式之所以能收到信号、触发定时器，就是因为thread->start()之后QThread内部会默认调用exec()开启事件循环。

要在子线程中使用QTimer，推荐用moveToThread + 在Worker内部创建QTimer：

class Worker : public QObject { Q_OBJECT public: explicit Worker(QObject *parent = nullptr) : QObject(parent) { m_timer = new QTimer(this); connect(m_timer, &QTimer::timeout, this, &Worker::onTimeout); } public slots: void start() { m_timer->start(1000); } void stop() { m_timer->stop(); } private: QTimer *m_timer; };

这样QTimer跟随Worker对象一起移动到了子线程，它的超时信号也会在子线程的事件循环里触发。

4.3 并发访问同一数据结构导致随机崩溃：加锁还是换消息?

跨线程共享一个QHash或者QList时，如果多个线程同时读和写同一个内存位置，那崩溃纯属看运气。Qt提供的解决思路有两类——加锁或者发消息。

加锁我一般用QMutex或者QReadWriteLock：

QMutex mutex; QHash<int, QString> data; // 线程A写入 mutex.lock(); data.insert(1, "hello"); mutex.unlock(); // 线程B读取 QMutexLocker locker(&mutex); QString value = data.value(1);

QMutexLocker是RAII风格的锁，函数返回或异常时自动解锁，推荐优先使用。

更“Qt化”的做法是避免共享状态：数据在线程间传递而不是多个线程同时访问。比如用信号槽传送一份数据拷贝，用QEvent自定义事件投递，用QtConcurrent::mappedReduced做数据并行。这个设计原则不仅让代码线程安全，调试时也轻松很多。如果你发现自己在一个多线程应用里到处加锁，那多半是数据流设计出了问题，而不是锁不够多。

我自己把共享队列改成信号槽传递之后，最直观的感受是“再也不担心锁顺序和死锁了”。队列、任务、结果全是通过信号流转，每个线程只处理自己的局部数据，最后汇总到主线程。

4.4 调试多线程的最佳姿势：日志、断点、线程视图

多线程问题最头疼的一点是不确定性问题。同样代码跑一千次，可能只有第十次崩溃。调试时我的建议是：

最大化利用qDebug输出，给每个线程的关键操作打日志，重点标注线程ID和时间戳。
不要轻易在断点处暂停，因为你暂停一个线程，其他线程还在跑，容易出现“本来不会崩，挂上调试器就崩”的错觉。
使用Qt Creator的“Threads”调试视图，可以看到当前所有线程的栈调用，定位阻塞发生在哪里。
如果问题只在Release版出现，考虑是不是优化改变了时序，尝试在关键区加些微小的延时观察变化。

再提一个排查崩溃的实用技巧：编译时开启core dump或者使用Application Output窗口的崩溃信息，通常在“处理完毕”末尾会有一串调用栈信息。如果崩溃发生在Qt内部，比如QWidget::repaint之类，那基本可以断定是线程访问了UI。

4.5 避免多线程内存越界：注意隐式共享与悬空指针

QString、QImage在Qt里是隐式共享的，也就是拷贝构造和赋值只增加引用计数，并不真正复制数据。跨线程传递这些类型时，如果两个线程同时修改数据，引用计数会变成不安全的（尽管Qt内部对引用计数做了原子操作，但对象自身的读写仍不是完全线程安全的）。所以跨线程传递数据时，最好明确数据在哪个线程“拥有”，不要两个线程共享同一个可变实例。

对于裸指针跨线程传递（比如new出来的对象地址发到另一个线程），更要小心。子线程还在用这个对象，主线程已经把它delete了，程序跑着跑着就崩。如果一定要用指针，建议用QSharedPointer管理生命周期，Qt的跨线程信号槽对QSharedPointer也有专门优化，比裸指针安全得多。

注意事项与避坑清单

说了这么多，最后把最容易踩的坑汇总成清单，每一条都是实际开发中反复出现的：

永远不要在子线程直接操作QWidget及其子类，包括setText、setValue、show、hide。
不要在线程构造函数里直接调用moveToThread来移动自己，正确方式是在外部创建对象后再move。
不要在run()里直接操作线程对象自己的信号槽连接，以免产生所有权混乱。
线程结束前一定要确保和它关联的所有QObject对象都清理干净，deleteLater比delete更安全。
使用QThreadPool时注意任务对象的setAutoDelete属性，默认为true，如果手动delete任务对象可能会二次释放崩溃。
跨线程传递自定义类型必须用qRegisterMetaType注册，这步不做后面调试会一头雾水。
不要指望QThread::terminate能安全退出线程，除非你确定线程里没有持有任何资源。
调试多线程时减少脑内推理，多依赖日志和线程视图，问题定位会快很多。

多线程后续还可以这样扩展

这一篇算是把Qt多线程的地基打完了：三种主流实现方式、线程生命周期管理、跨线程通信机制、常见崩溃排查思路。下一期我打算重点拆解Qt的信号槽连接方式对线程上下文的影响，比如DirectConnection、QueuedConnection、BlockingQueuedConnection各自的坑和适用场景，顺便讲一讲生产者消费者模型在Qt下的通用写法。还有QThreadPool调优、QFuture的高级用法（比如then链式调用、取消机制、进度回调），这些都是真实项目里会拿来做架构设计的硬核玩法。

我个人在实际项目中的体会是：多线程方案没有银弹，最有效的路就是先把每种方案的适用边界摸熟，然后在项目里建立一套约定俗成的规范，比如“凡是耗时任务一律走signal-slot，凡是纯计算优先QtConcurrent，凡是常驻后台服务一律moveToThread”，规范立住了，代码自然不容易翻车。如果看完这一篇你准备动手重构那个卡顿的老程序，建议先从最简单的QtConcurrent::run开始，把耗时函数挪出去，感受一下界面秒变流畅的爽感，再逐步进阶到完整线程模式，这样信心建立得快，踩坑也踩得心里有数。

Qt多线程入门：从界面卡死到线程方案选型与实战