Worker 对象 moveToThread 后到底该谁来 delete

为什么 Demo 没问题项目里就开始炸在很多 Qt 项目里我们习惯把耗时任务丢给 Worker然后moveToThread到新线程里去处理。Demo 写完点几下按钮一切正常。但把同样的逻辑搬到项目里尤其是界面复杂、Worker 链接信号槽多的时候程序一退出就闪退——那种堆栈一堆pure virtual method called的绝望。我以前也觉得Worker 是 QObject直接delete或者deleteLater应该没问题。Demo 能跑不代表项目能扛——关键在于线程归属和事件循环。这个锅很多时候不是 Qt 的Qt 对 QObject 的 delete 有严格规则对象只能在其所属线程的事件循环里安全析构。WorkermoveToThread后它的线程归属改变了。很多同学第一反应是我在主线程 calldeleteLater()不就行了吗结果短期没事长期开启多个 Worker界面频繁关闭就会碰到闪退。原理很简单worker-moveToThread(workerThread);connect(worker,Worker::finished,worker,QObject::deleteLater);这里deleteLater()会把对象销毁请求放到 Worker 所在线程的事件循环里。如果 Worker 所在线程还没启动或者线程退出太快deleteLater根本没机会执行对象就成了野指针。Demo 小量调用偶尔无感但项目场景下必翻。真正麻烦的是后期维护我踩过的项目里有的同事习惯在主线程直接delete worker;或者 Worker 里调用delete this;。短期能用但一旦信号槽还在触发或者 Worker Thread 还没结束程序就崩。更糟的是有时闪退只在特定机子或者特定顺序触发定位极难。我后来一般会这样处理我总结了一个套路稳定又安全autoworkerThreadnewQThread;autoworkernewWorker;// Worker 先绑定信号槽connect(worker,Worker::finished,workerThread,QThread::quit);connect(worker,Worker::finished,worker,QObject::deleteLater);connect(workerThread,QThread::finished,workerThread,QObject::deleteLater);worker-moveToThread(workerThread);workerThread-start();这个套路有什么好处线程归属明确deleteLater 在 Worker 所在线程执行线程安全退出线程退出自动 quit析构安全无内存泄漏Worker 和 Thread 都能自动删除注意如果你在 Worker 里直接delete this短期没事但只要信号槽还连着 Qt 事件循环闪退就回来了。常见坑或经验提醒千万别在主线程 delete moveToThread 后的 WorkerdeleteLater必须保证事件循环在跑Demo 少量调用不会显现问题项目高并发和多次退出会放大风险Worker 对象不要直接持有父对象否则父析构顺序可能打乱线程归属什么时候别硬套这套方案如果 Worker 真的是短命、只在调用函数里临时跑一次线程马上退出你可能直接用 lambda 或者 QtConcurrent::run 就够了。问题是大量 Worker 或循环任务时严格的归属和 delete 管理不能省。总结一句Qt 很多坑不是 API 难而是你在错误的场景里用了它。Worker moveToThread 后的 delete短期没事长期必翻。记住线程归属和事件循环别让项目来教你付学费。