Qt UI组件非线程安全，必须在主线程操作；跨线程更新需用Qt::QueuedConnection信号槽、QMetaObject::invokeMethod或事件循环投递，严禁子线程直接访问UI对象或其指针。
QLabel、QPushButton、QLineEdit）不是线程安全的，任何在非创建线程（即非主线程）中调用其成员函数（比如 setText()、show()）的行为都属于未定义行为——轻则界面卡死、刷新异常，重则程序崩溃或内存越界。这不是 Qt 的限制“风格”，而是底层 GUI 系统（X11/Win32/macOS AppKit）强制要求 UI 操作必须发生在唯一 UI 线程上。
为什么 Qt 的信号槽能跨线程更新 UI？
因为 Qt 的信号与槽连接方式决定了执行上下文：Qt::QueuedConnection（默认跨线程行为）会把槽函数打包成事件，投递到接收对象所在线程的事件循环中执行。也就是说，你写 emit updateReady("done")，真正调用 onUpdateReady() 的那一行代码，是在主线程的 QApplication::exec() 循环里跑的。
常见错误是没显式指定连接类型，又误以为 connect(sender, &S::sig, receiver, &R::slot) 在子线程发信号就等于槽也在子线程执行——其实如果 receiver 在主线程，且没传第 5 个参数，Qt 会自动选 Qt::AutoConnection，它根据 sender/receiver 所在线程决定连接类型；但一旦 receiver 被 moveToThread() 过，或 sender 和 receiver 线程不同，AutoConnection 就退化为 QueuedConnection。保险起见，建议显式写：
connect(worker, &Worker::updateUI, this, &MainWindow::onUpdateUI, Qt::QueuedConnection);
避免依赖隐式判断。
不依赖 Qt 信号槽时，怎么安全投递任务到主线程？
核心是：子线程不碰 UI 对象，只构造数据或函数对象，再交给主线程去执行。关键在于线程安全的任务队列 + 主线程事件循环驱动。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
std::function<void></void>封装要做的 UI 更新逻辑，捕获必要数据（注意生命周期，别捕获局部变量地址） - 用
std::mutex+std::condition_variable保护队列，避免竞争 - 主线程不能阻塞在
wait()上导致事件循环停摆——必须集成进QApplication的事件循环，比如用QTimer::singleShot(0, ...)或自定义QEvent投递 - 更轻量的做法：用
QMetaObject::invokeMethod(..., Qt::QueuedConnection)，无需自己维护队列
例如：
QMetaObject::invokeMethod(this, [this, text]{
ui->label->setText(text);
}, Qt::QueuedConnection);
这行代码可在任意线程调用，效果等价于发信号连槽，且不依赖对象间已建立的 connect 关系。
哪些操作看似“没动 UI”但实际危险？
以下写法在子线程中出现，哪怕没直接调用 setText()，也极可能 crash：
- 访问
ui->xxx成员指针本身（如果ui是在主线程 new 的，子线程读它的值仍属跨线程读取原始指针，C++ 标准不保证安全） - 调用
QObject::thread()判断所属线程（内部有锁，但非原子） - 对
QPixmap/QImage做绘制操作（它们不是完全线程安全的，尤其涉及QPainter时） - 调用
QWidget::repaint()或update()—— 这俩必须在创建该 widget 的线程中调用
真正安全的子线程行为只有：计算、IO、解析、加解密、编码转换……所有和 UI 对象无任何指针/引用/成员访问关系的操作。
真正麻烦的从来不是“怎么发信号”，而是“谁来管数据生命周期”和“主线程事件循环是否真的在跑”。很多崩溃源于子线程发射信号时，主线程的QApplication 已经退出，或者 receiver 对象已被 delete。务必检查 QObject::isDeleted() 或用 QPointer 做弱引用防护。 
