qt禁止在gui对象中直接使用std::thread，因其破坏线程亲和性、导致信号槽跨线程调用崩溃；应采用qthread+movetothread()（推荐）、qthreadpool+qrunnable（适合短任务）或显式qt::queuedconnection确保安全跨线程通信。
Qt 本身不推荐在 QObject 子类（尤其是 GUI 对象）中直接用原生 C++11 std::thread，因为线程亲和性、信号槽跨线程传递、对象生命周期管理会立刻出问题。正确做法是用 Qt 自己的线程机制——QThread、moveToThread() 或 QThreadPool + QRunnable。
为什么不能直接 new std::thread 并调用 slot？
Qt 的信号槽默认是同线程调用（Qt::DirectConnection），如果从 std::thread 里 emit 信号或调用 GUI 对象的 slot，极大概率触发 QObject: Cannot create children for a parent that is in a different thread 或崩溃。Qt 要求：GUI 对象（QWidget、QMainWindow 等）只能在创建它的线程（通常是主线程）中访问。
-
std::thread创建的对象默认无QObject线程亲和性，不能直接 connect 到 GUI 对象的信号 - 手动用
moveToThread()补救也容易漏掉事件循环、deleteLater 时机等问题 -
QThread不是线程本身，而是线程的控制器；它内部自动管理事件循环（exec()），这是 Qt 跨线程通信的基础
QThread + moveToThread() 是最常用且安全的模式
核心思路：把耗时操作封装成独立的 QObject 子类，用 moveToThread() 把它移到新线程，再通过信号触发执行——所有跨线程交互都走 Qt 的事件系统，由元对象系统自动序列化。
- 不要重写
QThread::run()，除非你明确要接管底层线程控制（极少需要） - 工作对象必须继承
QObject，且不能在构造时指定 parent（否则会被绑定到创建线程） - 启动流程固定：
QThread实例 start() → 工作对象 moveToThread() → 发送信号触发 slot（该 slot 就在目标线程执行） - 示例关键片段：
class Worker : public QObject {
Q_OBJECT
public slots:
void doWork() {
// 这个函数会在新线程里执行
emit resultReady(42);
}
signals:
void resultReady(int);
};
// 在主线程中：
QThread thread;
Worker worker;
worker.moveToThread(&thread);
connect(&thread, &QThread::started, &worker, &Worker::doWork);
connect(&worker, &Worker::resultReady, this, &MyClass::handleResult);
thread.start(); // 启动线程并触发 started 信号
QRunnable + QThreadPool 更适合短任务，但要注意对象生命周期
适用于无状态、无信号依赖、执行完就销毁的计算型任务（比如图像处理单帧、JSON 解析）。它比 QThread 轻量，但不提供事件循环，也不能直接 emit 信号到主线程对象——必须用 QMetaObject::invokeMethod() 或 lambda 捕获方式回调。
-
QRunnable不是QObject，无法直接 connect/signal - lambda 回调需确保捕获的指针（如
this）在线程结束前仍有效；建议用QPointer或 weak_ptr 做防护 - 默认线程池大小是 CPU 核心数，长时间阻塞任务会拖慢其他任务，必要时用
QThreadPool::setMaxThreadCount() - 示例：
auto runnable = new MyRunnable([this](int result) {
if (this) { // 防空指针
QMetaObject::invokeMethod(this, [this, result]() {
ui->label->setText(QString::number(result));
}, Qt::QueuedConnection);
}
});
QThreadPool::globalInstance()->start(runnable);
信号槽跨线程连接必须显式指定 Qt::QueuedConnection
即使用了 moveToThread()，如果 connect 时没写连接类型，Qt 默认用 Qt::AutoConnection —— 它会根据 sender/receiver 是否同线程自动选 Direct 或 Queued。一旦 sender 和 receiver 线程判断出错（比如 receiver 被 move 了但 sender 缓存了旧线程信息），就会静默降级为 Direct 导致崩溃。
- 只要 sender 和 receiver 不在同一线程，就必须写
Qt::QueuedConnection - 尤其注意：connect 发生在主线程，但 receiver 后续被 move 到子线程，此时必须用 Queued，否则后续 emit 会 crash
- 错误写法：
connect(worker, &Worker::done, this, &MyClass::onDone) - 正确写法：
connect(worker, &Worker::done, this, &MyClass::onDone, Qt::QueuedConnection)
真正难的不是写几行线程代码，而是理清对象归属线程、信号触发路径、deleteLater 时机这三者的耦合关系。Qt 的线程模型本质是“事件驱动线程”，不是“裸线程封装”。漏掉一个 Qt::QueuedConnection，或者在子线程里直接调 widget->update()，程序可能跑几天才崩一次，调试成本远高于初期多写两行约束。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
