子线程不能直接调用UI方法，必须通过Qt::QueuedConnection信号槽、qRegisterMetaType注册自定义类型、QMetaObject::invokeMethod或确保主线程事件循环运行来安全跨线程通信。
子线程不能直接调用 setText()、update()、setValue() 等任何 UI 方法，这是 Qt 的硬性限制，不是建议——越界操作大概率导致崩溃或“递归重绘”错误（如 QWidget::repaint: Recursive repaint detected），且问题常偶发、难复现。
信号槽跨线程连接必须显式用 Qt::QueuedConnection
很多人以为 connect() 默认就能跨线程安全工作，其实不然。虽然 Qt::AutoConnection 在发送者和接收者跨线程时会自动降级为队列连接，但依赖自动推断风险高：
- 若接收对象后来被
moveToThread()到其他线程，而你没注意连接类型，信号可能被同步执行（Qt::DirectConnection），直接在子线程里调 UI 函数，当场崩溃 - Qt 5.15+ 对某些隐式转换场景的自动判断更保守，容易退化为失败连接
- 调试时看不到连接是否生效，出问题只能靠日志或断点排查
所以务必显式指定：
connect(worker, &Worker::dataReady, this, &MainWindow::onDataReceived, Qt::QueuedConnection);
这样信号一定会被序列化进主线程事件循环，槽函数一定在主线程执行。
传递自定义结构体前必须注册元类型
如果信号参数是 struct、std::string、QVector 这类非 Qt 内置类型，不注册就 emit，程序不会报错，但槽函数收不到数据（参数为默认构造值），且 Qt 会静默丢弃该信号——非常难排查。
注册分三步，缺一不可：
- 在头文件中声明：
Q_DECLARE_METATYPE(Msg) - 在
main()或任意 .cpp 文件全局作用域注册：qRegisterMetaType("Msg"); - 若结构体含指针或需深拷贝，还需实现
operator 和operator>>（用于队列序列化）
注意：注册必须在 QApplication 构造之后、任何跨线程 emit 之前完成。
QMetaObject::invokeMethod() 是轻量替代方案
当只是偶尔更新一次 UI（比如任务结束弹个提示），不想额外写信号/槽，可用 invokeMethod() 直接在主线程调用函数：
QMetaObject::invokeMethod(this, [this]() {
ui->label->setText("Done!");
}, Qt::QueuedConnection);
优势是代码集中、无须声明信号；但要注意：
- lambda 必须捕获明确，避免悬空指针（比如捕获
this前确保对象未析构） - 不能传非
const引用或右值引用参数（队列机制只支持值拷贝或 const 引用） - 频繁调用会堆积大量事件，不如信号槽语义清晰
别用 QTimer::singleShot(0, ...) 模拟跨线程调用
网上有教程说用 QTimer::singleShot(0, this, &MainWindow::updateUI) 可以“切回主线程”，这本质是利用事件循环延迟执行，但它不保证线程上下文——如果当前就在主线程，它仍会立即执行；如果在子线程，它确实会排队到主线程。但问题在于：
- 没有线程绑定保障，一旦调用点被挪到主线程逻辑里（比如按钮点击后又启动了新任务），就会变成同步调用，失去保护
- 无法传递参数（除非用 lambda + invokeMethod 组合，那就绕远了）
- 语义模糊，后期维护者很难一眼看出这是跨线程通信意图
真正需要跨线程，就老实用信号槽或 invokeMethod，别图省事埋坑。
最易被忽略的一点：所有跨线程通信的前提，是主线程必须运行着事件循环（即 QApplication::exec() 正在跑）。如果你在子线程里 emit 信号，但主线程正卡在某个阻塞调用里（比如没加超时的 QProcess::waitForFinished()），那信号就永远等在队列里，UI 也不会更新——检查主线程是否“活着”，比检查信号连没连上还重要。
