今日学习：Qt 多线程——QThread 与线程亲和性

前九天我们先后攻克了 C++ 的资源管理（RAII、移动语义、内存管理）、容器与算法、锁与并发原语，也见识了 Qt 的 Model/View 与网络编程。但桌面客户端真正的分水岭问题还没有正面回答：一个需要 3 秒才能完成的任务，如何做到不冻结界面？

今天学习 Qt 的多线程模型：QThread、线程亲和性（thread affinity）、跨线程信号槽与 QtConcurrent。它与原生 std::thread 是两套心智模型——Qt 不是"更花哨的线程库"，而是一套基于事件循环与消息传递的协作式并发。搞懂它，你才能从"会写多线程代码"进阶到"会设计多线程应用"，这也是 8/9 锁原语的天然下一站：锁是保底手段，而 Qt 的线程模型让你大多数时候根本不需要锁。

一句话说清今天的核心：每个 QObject 都属于创建它的线程；跨线程协作不靠共享内存，靠"信号 + 队列连接"把数据和调用打包成消息，投递到对方线程的事件循环里处理。

1. 线程亲和性：一切 Qt 并发问题的根源

每个 QObject 从构造那一刻起，就"属于"创建它的线程——这个属性叫线程亲和性（thread affinity）。对象的事件、定时器、以及槽函数的排队执行，全部发生在它所属线程的事件循环里。理解这一点，Qt 并发的 80% 的坑都能绕开。

这里有一个极易混淆的概念：QThread 对象本身只是一个"线程句柄"，它活在创建它的线程（通常是主线程）里；而它管理的那条原生线程，默认只负责执行 run()。两条"线程"不是一回事。由此得到两条推论：

• 推论一：槽函数在哪个线程执行，取决于 receiver 对象的亲和性，与 sender 无关。
• 推论二：从一个线程直接调用另一个线程对象的普通成员函数，本质上是无保护地并发访问——数据竞争，编译器不拦你，崩溃随机发生。

2. QThread 的两种用法

旧派：子类化 QThread，重写 run()。你只能往 run() 里塞一段自包含的逻辑，无法和外部协作；更致命的是，很多人误以为"槽函数也会跑在子线程"——其实 QThread 对象的亲和性还在主线程，它的槽函数依然在主线程执行。

推荐：Worker 对象 + moveToThread()。把业务对象整体搬进子线程，它的槽、信号、定时器、事件全部跟着走。线程启动后，通过队列连接发来的槽调用都在子线程执行。这是 Qt 官方文档明确推荐的模式：

// 推荐模式：worker 对象 + moveToThread
class Worker : public QObject {
    Q_OBJECT
public slots:
    void doWork() {            // 在子线程的事件循环里执行
        auto result = heavyCompute();
        emit done(result);     // 队列连接 → 回 UI 线程
    }
signals:
    void done(int result);
};

// 主线程装配
QThread thread;
Worker worker;                   // 先属于主线程
worker.moveToThread(&thread);    // 改变亲和性（关键一步）
connect(&thread, &QThread::started, &worker, &Worker::doWork);
connect(&worker, &Worker::done, &label, [](int r){ /* 在 UI 线程执行 */ });
thread.start();

3. 事件循环与队列连接

每条线程都可以拥有自己的 QEventLoop（QThread::exec() 启动它）。定时器、事件投递、队列连接全都依赖它——没有事件循环的线程，收不到队列连接。

connect() 默认使用 AutoConnection：连接建立时比较 sender 与 receiver 的线程亲和性——同线程则直连（等同普通函数调用）；跨线程则队列连接：把"这次调用"连同参数一起打包成事件，投递到接收者线程的事件队列里，由它的循环取出执行。这意味着：

• 参数必须可拷贝构造（跨线程传的是副本，不是共享引用）；
• 自定义类型必须 Q_DECLARE_METATYPE + qRegisterMetaType() 注册，否则连接静默失效；
• 执行是异步的：emit 之后函数立即返回，接收方稍后才执行。

4. 任务级并发：QtConcurrent 与线程池

如果只是"跑一个函数、拿一个结果"，不必亲自管理线程生命周期：QtConcurrent::run() 把函数丢进 QThreadPool（全局池，默认按 CPU 核数），返回 QFuture；再用 QFutureWatcher 监听完成信号，把结果带回 UI 线程。这等价于前端的 Promise——异步任务 + 回调，线程池替你管好了线程的创建与回收。

5. 一个反直觉的结论

在 Qt 的世界里，线程同步的需求远小于裸 std::thread 世界。跨线程传数据用"信号 + 参数拷贝"，而不是共享容器加锁；QMutex、QReadWriteLock 是保底手段，不是默认手段。8/9 学的锁原语在这里的定位是"最后一道防线"，而第一道防线是架构：数据只在一条线程里被修改，需要共享时用消息传递。

Qt Creator：打开大型 C++ 项目时，代码模型（ClangCodeModel）的解析、索引、语义分析全部在后台线程完成，通过信号把符号表与高亮信息回传 UI。索引期间编辑器依然可滚动、可输入——如果放在 UI 线程解析，打开项目会"假死"几十秒，用户早就卸载了。

Chrome：每个渲染进程内部严格分为主线程（UI/渲染）、IO 线程、合成线程，线程间用任务队列（task queue）传递消息，严禁跨线程直接访问 DOM 与布局数据。这套纪律与 Qt"QObject 只在自己的线程里被碰"完全同构——浏览器团队用二十年血泪验证了它。

VSCode：界面（渲染进程）与扩展宿主（Node 进程）分离，通过 postMessage 异步通信；文件读写、语法分析、语言服务全部在后台。你在 VSCode 里打字永远不卡，不是因为快，是因为打字路径上没有一件重活。

微信 / QQ 桌面端：消息收发、图片解码、数据库写入都在工作线程，主线程只做渲染与输入事件。想象一下收消息风暴时如果每条消息都在主线程解码图片——窗口必然"假死"。JetBrains IDE 的后台索引 + 进度条，同样是"worker 线程发进度信号"的教科书。

共性结论：所有大型桌面软件都把"UI 线程 16ms 纪律"当作铁律——任何超过一帧预算的阻塞都移到后台；线程间通信一律走消息（信号/task queue/postMessage），而不是共享内存。这不是风格偏好，是工程生存法则。

1. 子类化 QThread 并把所有业务逻辑塞进 run()，还指望槽函数跑在子线程。原因：QThread 对象本身活在主线程，槽函数按 receiver 亲和性执行，仍然在主线程——"以为并发，实则串行"。避免：用 worker + moveToThread()。
2. 跨线程直接调用 UI 对象的方法（绕过信号槽）。原因：编译器完全不拦，运行时数据竞争导致偶发崩溃，且极难复现。避免：一律走信号槽，参数按值传递。
3. 自定义类型跨线程发信号但没注册元类型。原因：connect 需要类型信息才能拷贝参数，未注册时连接在运行时静默失败或打印 Cannot queue arguments of type。避免：Q_DECLARE_METATYPE + qRegisterMetaType，或用内置类型。
4. 退出时忘记 quit() + wait()。原因：线程还在运行，QThread 析构时直接崩溃：QThread: Destroyed while thread is still running。避免：统一生命周期——任务结束 quit()，析构前 wait()（或 connect finished → deleteLater）。
5. 用"共享 QList + QMutex"当跨线程数据通道。原因：锁竞争、忘记加锁的角落、加锁顺序不一致导致死锁——把并发复杂度全揽到自己身上。避免：用信号槽传拷贝；大块只读数据用 std::shared_ptr<const T> 传递并明确同步点。
6. 在 UI 线程里 QThread::msleep 模拟延迟或做同步 IO。原因：直接冻结界面，用户感知为"假死"。避免：用 QTimer 延后，把 IO 放后台线程或改用异步 IO（QNetworkAccessManager 本身就是异步的，不需要为此开线程）。

// ❌ 错误示范：把"线程"当成"代码块容器"
class MyThread : public QThread {
    Q_OBJECT
protected:
    void run() override { ... }   // 这里确实在子线程
public slots:
    void onData() { ... }          // 但这里仍在主线程！
};
// QThread 对象属于创建它的线程；子类化只影响 run()，不影响槽函数