为什么Qt槽函数调用QLabel的setText/repaint时GUI线程响应缓慢

问题诱因 #

这个问题的核心是窗口初始化流程和子线程触发UI更新的时机冲突，加上冗余的repaint调用放大了卡顿：

1. 你在MainWindow的构造函数里就启动了子线程，而构造函数执行完才会走到main函数的w.show()触发窗口显示。窗口从show到完全完成首次渲染、系统窗口管理器释放渲染锁，中间会有几百毫秒到数秒不等的耗时（和系统开启的窗口开启动画、合成器策略直接相关）。
2. 当你把子线程sleep设为200ms时，触发槽函数的时机刚好卡在窗口初始化渲染完成之后，主线程事件队列空闲，repaint调用可以立刻执行完成，所以耗时短。
3. 当sleep设为500ms时，触发槽函数的时机刚好卡在系统窗口动画/合成器锁定渲染资源的阶段，repaint是同步调用，会一直阻塞到系统允许渲染为止，就会出现数秒的耗时。
4. 额外的冗余操作：QLabel::setText()执行时内部已经自动触发了update()请求重绘，你手动再调用repaint属于不必要的同步强制重绘，进一步放大了阻塞概率。

解决方案 #

按优先级执行以下操作即可解决问题：

• 直接删除槽函数中手动调用的ui->label_resultSimilarity->repaint();行，Qt控件在内容变更后会自动触发重绘，不需要手动干预。
• 不要在主窗口构造函数中启动子线程，改为窗口完全初始化后再启动：可以重载showEvent，或者在构造函数中加QTimer::singleShot(1000, m_testThread, &TestThread::start);延迟1秒启动线程，避开窗口初始化渲染的高峰。
• 如果确实需要手动触发重绘，优先用update()而非repaint：update()是异步请求，会合并多个重绘请求到下一次事件循环处理，不会阻塞当前执行逻辑，性能更优。
• 可选：测试时可以暂时关闭系统的窗口开启动画、桌面合成器效果，排除系统层面的渲染阻塞影响。

按照上述方案修改后，不管子线程sleep时长设为多少，UI更新耗时都会稳定在毫秒级。

内容的提问来源于stack exchange，提问作者yzy888