qt工业组态软件本质是7×24稳定运行的数据调度中枢，需分层解耦：通信层用独立线程+信号推送datapoint，主窗口仅监听valuechanged刷新；qml适合视觉模块，qwidget胜任强交互控件；串口rtu须调优缓冲区、禁用rts/cts、帧校验失败后清空缓冲；部署应动态链接并合规处理lgpl及字体资源。
Qt开发工业组态软件不是“用QWidgets拖几个控件+连串口”就能交付的事——它本质是构建一个可配置、可扩展、能7×24小时稳定运行的数据调度中枢，界面只是最外层的皮肤。
为什么不能直接在MainWindow里写Modbus读取逻辑
很多初学者一上来就把QModbusClient、QTimer、数据解析、控件更新全塞进主窗口类，结果现场一跑就出三类问题：
- 通信异常时界面卡死（主线程阻塞在
QModbusReply::waitForFinished()） - 新增一个PLC型号就得改主窗口代码，没法热插拔协议
- 历史曲线刷新和报警判断互相抢
QPainter资源，帧率掉到10fps以下
正确做法是把通信层彻底剥离：用独立线程（或QThreadPool）运行QModbusTcpClient，通过信号（非Qt::DirectConnection）把解析后的DataPoint结构体推给业务层。主窗口只做一件事：监听DataModel::valueChanged信号并刷新控件。
QML + Widgets混合架构怎么选控件边界
纯QML适合动态仪表盘、3D设备拓扑等视觉密集型模块；但阀门、按钮、报警列表这类强交互、需精确像素控制的控件，仍建议用QWidget子类实现。关键分界点是：
- 需要响应
QEvent::TouchBegin且带手套操作 → 用QPushButton重写paintEvent，禁用鼠标悬停效果 - 要绑定实时趋势图（每秒200点）→ 用
QCustomPlot或QChartView，别用QQuickPaintedItem反复重绘 - 组态编辑器本身（拖拽控件、连线、属性面板）→ 必须QWidget，QML Designer插件生态不支持工业控件元数据描述
跨层通信用QMetaObject::invokeMethod()调用目标线程的槽函数，避免跨线程直接访问UI对象。
串口Modbus RTU通信的稳定性陷阱
QSerialPort在工控现场极易丢包，不是驱动问题，而是默认参数根本不适配工业环境：
- 必须关闭
QSerialPort::DataTerminalReadySignal和QSerialPort::RequestToSendSignal（多数PLC不接RTS/CTS） - 设置
setReadBufferSize(65536)，否则高频率读取时内核缓冲区溢出 - 超时不能依赖
waitForReadyRead()，要用QTimer配合bytesAvailable()轮询，防止单次readAll()截断Modbus帧 - 帧校验失败后，必须清空接收缓冲区再发下一帧——否则残留字节会污染后续解析
实测发现：某国产PLC在115200波特率下，连续发送100帧无校验错误，但只要中间有1次QSerialPort::errorOccurred，后续3帧必错，必须强制clear()后再重发。
部署时静态链接Qt库的法律与技术双坑
很多团队为简化部署选择静态编译，但LGPL协议要求你必须提供目标文件（.o/.obj）供用户重新链接——这在工业项目里几乎不可行。更现实的方案是：
- Windows下用
windeployqt+ 手动补全msvcp140.dll和vcruntime140.dll（注意VC++2015/2019版本匹配） - Linux嵌入式平台用
patchelf修正rpath，别依赖LD_LIBRARY_PATH - ARM工控机上Qt 6.5的
libQt6Core.so必须用arm-linux-gnueabihf-工具链编译，混用x86交叉编译器会导致QThread创建失败
最容易被忽略的是字体：现场工控机常无网络，QFontDatabase::addApplicationFont()加载的字体必须打包进资源文件（:fonts/xxx.ttf），且在main()最开头调用，否则中文报警框显示方块。
