做 Qt 项目的人，大概率都说过类似的话：“这玩意儿真别扭。”
比如一个看起来不复杂的需求——做个设备状态页，带参数配置、实时曲线、告警弹窗，再加个串口通信。demo 阶段跑得挺欢，界面一搭、信号槽一连，感觉效率高得离谱。结果真到项目里，线程开始拧巴，UI 开始卡顿，样式表越写越乱，发布包一做大，平台兼容问题也跟着冒出来。

这时候，很多人就开始吐槽 Qt：MOC 魔法味太重、信号槽调试不直观、QSS 不好控、跨平台也没想象中那么“无脑”。
但有意思的是，吐槽归吐槽，真到下个桌面项目、上位机项目、配置工具项目开干时，很多团队还是会选 Qt。

这事其实一点都不矛盾。Qt 被吐槽，不是因为它没价值，而是因为它太常被拿去干“又杂又急又难维护”的活。

核心讲解

Qt 在 Qt/C++ 开发里的核心作用，说白了就一句话：它不是单纯一个 GUI 库，而是一整套工程化开发框架。

很多人低估 Qt，觉得它就是画界面的。真做过项目就知道，大家用 Qt，往往不是因为按钮好画，而是因为它把一堆原本分散的能力揉到一起了：
网络、串口、数据库、线程、定时器、文件系统、JSON/XML、插件、国际化、事件机制、模型视图……这些东西单独拼 C++ 原生库当然也能做，但一旦进入项目，光“怎么把这些模块顺畅地接起来”，就够你喝一壶。

Qt 最大的价值，不是某个类有多强，而是它提供了一套统一的开发语境。
比如你做工业上位机，底层串口采数据，工作线程解析协议，主线程更新界面，异常信息落库，还要支持后面加新设备。Qt 的对象模型、事件循环和信号槽机制，刚好能把这条链路串起来。

connect(worker, &DeviceWorker::dataReady,
        this, &MainWindow::updateUi);

这行代码看着简单，真正的价值不是“连上了”，而是它把线程间通信、对象解耦和界面响应这几个问题一起兜住了。
你可以吐槽它不像现代 C++ 那么“纯”，但项目里很多时候，能稳稳落地，比语法是不是优雅更重要。

应用

我见过不少项目，前期觉得 Qt 用得很爽，后期开始骂，根源通常不在 Qt 本身，而在于“拿它快速堆出了一个能跑的系统，却没按工程方式收拾它”。

最典型的是桌面客户端和上位机。前期为了赶进度，界面逻辑、通信逻辑、业务逻辑全塞进 MainWindow，信号槽一顿连，功能确实出得快。可一旦需求变化，比如要支持多设备、插件扩展、权限管理，代码立刻变成一锅粥。
这时候很多人会说 Qt 不行，其实不是 Qt 不行，是你把它当脚手架用了，却拿它撑长期维护。

真正项目里，Qt 通常是这么落地的：
UI 层只负责展示和交互，设备通信放到独立 worker 或 service，数据通过信号槽或中间层派发，数据库和配置模块单独封装，插件化需求则通过接口加 QPluginLoader 做扩展。
这么拆完之后你会发现，Qt 的优势反而出来了：模块间边界清晰，跨线程通信不至于满天飞 callback，跨平台发布也比自己拼框架省心得多。

常见坑或经验提醒

Qt 最容易被骂的几个点，其实也正是最容易踩坑的地方。

一个是把信号槽当“万能胶”。前期省事，后期谁触发谁根本说不清，调 bug 能把人整崩。信号槽适合做模块通信，不适合替代清晰的业务结构。
另一个是线程模型理解不到位。很多人以为对象 moveToThread 了就完事，结果定时器、socket、对象归属全乱掉，现场一接设备，莫名其妙的卡死和崩溃全出来了。
还有一个老坑：QSS 看着爽，维护起来非常痛苦。小项目用它改改样式挺快，大项目全靠 QSS 堆皮肤，最后改一个控件，整页都可能受影响。

所以，Qt 不是不能乱用，而是它一旦被乱用，反噬来得特别快。
它太适合快速起项目了，这反而容易让人低估架构的重要性。

总结

为什么很多人吐槽 Qt，却还是继续用 Qt？
因为它确实有让人别扭的地方，但它也确实解决了项目里最现实的问题：开发效率、工程整合、跨平台落地和维护成本。

说白了，Qt 不是“最时髦”的选择，也不一定是“最优雅”的选择，但它经常是那个最像项目答案的选择。
你可以嫌它老、嫌它重、嫌它有历史包袱，但当你真要在 Windows 上做个能跑、能发版、能连设备、能让客户现场别出事的系统时，最后多半还是会把 Qt 捡回来。

这东西平时看着不复杂，一上项目就容易拧巴。
也正因为它真的扛过事，所以大家才会边吐槽，边继续用。