Qt物联网平台设备监控模块：从串口到QCustomPlot波形实战-代码聚汇网

Qt物联网平台设备监控模块：从串口到QCustomPlot波形实战

Qt物联网设备监控

|难度：普通|阅读约 36 分钟

做Qt物联网综合管理平台，第一件要想清楚的不是界面能画得多漂亮，而是设备监控模块里的数据监控怎么把一条真实数据从传感器稳定搬到界面。我最近在整理一套0.2.1版本的Qt物联网综合管理平台源码时，把设备监控模块单独拎出来重新梳理了一遍，过程中用到了QCustomPlot做实时曲线，又在时域数据和频域数据之间做转换，最终把数据监控、波形显示、HTTP上报串整条链路完整跑通。这篇文章不是什么华丽的架构课，就是把这套源码里最常用的一截干货拆开讲：设备怎样接入、数据怎样解析、QCustomPlot怎样画好时域图和频域图、发布到别的机器时又容易卡在哪些报错上。

如果你正要做物联网毕业设计、企业设备看板，或者准备在现有Qt项目里加一套多通道设备监控模块，这篇文章可以直接当作参考。我默认你至少会建一个Qt工程，能写基本C++，暂时不熟悉网络编程和FFT也能跟上，因为后面的内容会一步步展开。

1. 设备监控模块到底包含哪些东西，先拆边界

1.1 从0.2.1版本模块列表看整体骨架

我看到的这套Qt物联网综合管理平台源码版本号还停在0.2.1，软件模块列表里第一个就是“设备监控模块”，下面跟的是“数据监控”。这类源码的常见结构通常不只是画几个曲线，而是围绕设备资产、通信链路、实时数据、历史存储、报警通知几条线展开。一个完整的设备监控模块，至少需要处理以下场景：

设备在线状态管理：判断设备是否连接、心跳是否超时、通信链路是否断开。
实时数据监控：定时/触发式采集设备的电流、电压、温度、湿度、开关状态等数据，并在界面刷新。
历史数据落库：不把历史数据全堆在内存里，需要按规则写入数据库，方便后续查趋势。
阈值告警：当某个通道的数据超过上下限，产生告警记录并通知用户。
设备远程控制：部分场合还要下发命令，比如控制继电器开关、修改采样频率。

这些能力如果都塞进一个“监控页面”里，代码很快就会乱。所以做源码拆解时，我会先按数据流把模块边界划出来：设备接入层负责“收数据”，协议解析层负责“读懂数据”，核心管理类负责“分发数据”，界面层负责“展示数据”，数据库和上报模块负责“保存和转发数据”。

对于0.2.1这个版本来说，我的建议是不要一开始就追求完整的微服务架构。先把设备监控模块做扎实，后面再扩展控制、告警和报表，成熟度会高很多。

1.2 数据监控在整套系统里的位置

数据监控是设备监控模块的心脏。很多人以为数据监控就是“写一个定时器，定时读串口，然后画曲线”，其实没那么简单。设备数据从物理世界进入Qt界面，中间要经过采样、编码、传输、校验、解析、缓冲、显示多个环节，任何一个环节掉链子，界面上看到的曲线都会失真。

我在这套源码里把数据监控抽象成了这样一条链路：

设备端定时采样，并按照约定协议组帧发送。
平台侧通信管理器接收原始字节流。
协议解析器对字节流做拆包、校验、解析，得到结构化数据。
数据中心线程把数据按设备ID和通道号写入环形缓冲，并发出信号。
UI曲线组件读取缓冲数据进行实时绘图，数据库模块异步写入历史记录。
如果启用了告警，还要在数据入口处做阈值比较。

这套链路里最关键的一个设计原则是：采集线程一定不能直接操作UI控件。串口数据到达时间和UI刷新时机不是一回事，如果在串口readyRead信号里直接调用QCustomPlot的addData，数据量一旦增大，界面就会卡成PPT。正确做法是把数据先发到核心管理对象，再由管理对象统一发QVector数据块给绘图组件，批量刷新。

1.3 一个适合源码二次开发的类结构

我重新组织这套源码时，用到了下面几个核心类，供你二次开发时参考：

cpp复制class IotDevice {
public:
    QString deviceId;
    QString deviceName;
    bool isOnline = false;
    QList<DeviceChannel*> channels;
};

struct ChannelData {
    QString channelId;
    double value;
    QDateTime timestamp;
    int quality;
};

这里把设备和管理器分开，一个设备可以有多个通道。通道对应一路传感器或一个寄存器地址，比如一个电能表设备可以有Ua、Ub、Uc三个电压通道。这种结构在界面上特别好映射：左侧放设备树，中间放通道实时表格，右侧放选中通道的曲线。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 设备数据从哪儿来：串口、Modbus和TCP自定义协议

2.1 串口接入，线程模型比串口参数更容易踩坑

在0.2.1的源码里，设备接入方式最常见的还是串口。很多物联网终端设备就是基于ESP32、ESP8266、STM32做的，这些MCU采集传感器数据后通过串口或者WiFi发出。Qt侧用QSerialPort收发串口数据是非常成熟的做法。

先看串口配置代码。假设设备波特率是9600，8个数据位，1个停止位，无校验：

cpp复制#include <QSerialPort>
#include <QSerialPortInfo>

QSerialPort* port = new QSerialPort(this);
port->setPortName("COM3");
port->setBaudRate(QSerialPort::Baud9600);
port->setDataBits(QSerialPort::Data8);
port->setParity(QSerialPort::NoParity);
port->setStopBits(QSerialPort::OneStop);
port->setFlowControl(QSerialPort::NoFlowControl);

if (!port->open(QIODevice::ReadWrite)) {
    qWarning() << "串口打开失败:" << port->errorString();
    return;
}

connect(port, &QSerialPort::readyRead, this, &SerialCollector::onReadyRead);

这里我有一个实际测试下来的建议：不要把数据处理逻辑直接全部塞进onReadyRead里。串口底层返回的数据不一定是完整的一帧，可能一次来了半帧，也可能一次来了好几帧。所以必须设置一个字节缓冲区，等到数据足够解析一帧时再处理。

cpp复制void SerialCollector::onReadyRead() {
    buffer.append(port->readAll());

    while (buffer.size() >= 8) {
        // 查找帧头
        int headerIndex = findFrameHeader(buffer);
        if (headerIndex < 0) {
            buffer.clear();
            return;
        }
        if (headerIndex > 0) {
            buffer.remove(0, headerIndex);
        }

        int frameLen = getFrameLen(buffer);
        if (buffer.size() < frameLen) {
            return; // 半包，等下一批
        }

        processFrame(buffer.left(frameLen));
        buffer.remove(0, frameLen);
    }
}

这段代码解决了一个非常容易让新手崩溃的问题：串口数据经常“粘包”和“拆包”，如果不做缓冲和帧长判断，解析结果就会错乱。很多设备调试日志看起来是乱码，本质上不是波特率错乱，就是没处理半包逻辑。

还有一点要特别提醒：QSerialPort对象最好由它所在的线程创建和销毁，不要在主线程创建一个串口对象，然后丢到工作线程去用，那样信号槽连接可能不生效，甚至出现神秘的崩溃。

2.2 Modbus协议接入时的CRC校验

如果你的设备是RS485总线上的Modbus设备，那就绕不开CRC16校验。我看到不少初学者直接用网上抄的CRC函数，抄错了也不知道，等设备端拒绝应答时才开始怀疑协议不对。一个可用的Modbus CRC16计算方式如下：

cpp复制quint16 modbusCrc16(const QByteArray &data, int len) {
    quint16 crc = 0xFFFF;
    for (int pos = 0; pos < len; pos++) {
        crc ^= (quint8)data.at(pos);
        for (int i = 8; i != 0; i--) {
            if ((crc & 0x0001) != 0) {
                crc >>= 1;
                crc ^= 0xA001;
            } else {
                crc >>= 1;
            }
        }
    }
    return crc;
}

CRC校验通过以后，Modbus的数据寄存器值还需要解析。比如读到的两个字节表示一个16位寄存器，如果寄存器定义是无符号整数，直接组成ushort即可；但如果设备是浮点数且采用了ABCD字节序，那就需要做字节序转换。我踩过的坑多半都在这里：电压显示成几千甚至几万，不一定是采集模块坏了，而是浮点字节序搞反了。

2.3 TCP/UDP自定义协议和设备网关上云

除了串口，网络设备接入是另一种常见方式。很多边缘网关或者带有以太网口的设备会直接通过TCP连接上位机，按固定协议上报数据。我自己用的比较简单高效的帧格式如下：

字段	长度	说明
帧头	2字节	固定为0xAA 0x55
设备ID	1字节	区分网关，最多255个
数据类型	1字节	0x01遥测、0x02状态、0x03告警
数据长度	2字节	小端表示
数据载荷	N字节	JSON或者二进制结构体
校验	1字节	简单异或，或者CRC

数据载荷这一块，我更推荐直接使用JSON字符串。虽然比二进制结构体浪费一点带宽，但调试时肉眼可见，Web端对接也方便。尤其在“边缘计算节点把校园物联网设备数据上云”这类应用里，边缘网关做一层MQTT/HTTP转发，Qt平台作为总控端接收网关的标准化数据，JSON的好处会被放大。

自己解析TCP流的时候，依然要沿用串口那套“缓冲区找帧头 + 按数据长度取整包”的逻辑。不要用QAbstractSocket读一次就take整包，因为TCP是字节流，没有天然消息边界。

3. QCustomPlot可视化：时域波形和频域谱线是怎样炼成的

3.1 为什么选QCustomPlot而不选QCharts

如果用Qt自带的QCharts做几条静态曲线，速度也还行。但是做物联网平台的数据监控时，通道数量多、刷新频率高、还要缩放拖拽，QCharts的实时表现往往不如QCustomPlot。QCustomPlot是纯C++实现、基于QPainter绘制的开源控件，曲线重绘性能极高，而且没有复杂的系统依赖，复制几个源文件就能接入工程。

这套源码里实际用到的QCustomPlot版本是2.x，编译时只需要把qcustomplot.h和qcustomplot.cpp加入工程。如果是MinGW套件，基本没有任何额外依赖。

3.2 用QCustomPlot实现实时时域波形

画时域波形，核心思路是把采样点当作横轴时间、纵轴幅值的点序列。设备采集到的电压、温度数据会不断地追加到QVector里，每次UI定时刷新时，把最新数据整块setData给曲线。

cpp复制// 初始化曲线
ui->customPlot->addGraph();
ui->customPlot->graph(0)->setPen(QPen(QColor(40, 110, 255)));
ui->customPlot->xAxis->setLabel("时间/s");
ui->customPlot->yAxis->setLabel("数值");

// 定时刷新，比如100ms刷新一次
void WaveWidget::refreshPlot() {
    QVector<double> xData, yData;
    xData.reserve(bufferA.size());
    yData.reserve(bufferA.size());
    for (int i = 0; i < bufferA.size(); ++i) {
        xData.append(bufferA.at(i).timestamp);
        yData.append(bufferA.at(i).value);
    }
    ui->customPlot->graph(0)->setData(xData, yData);
    ui->customPlot->xAxis->rescale();
    ui->customPlot->yAxis->rescale();
    ui->customPlot->replot();
}

有人问为什么不用addData一条条加，而是每次都用setData整体替换，因为addData触发的重绘策略是增量式的，当数据量到达几万点时，单次调用开销并不小。而setData加上一次replot能更好地控制刷新节奏，保证界面流畅度。

如果只是显示最近几秒的数据，建议画滚动窗口，比如固定显示最近512个点，然后x轴范围直接setRange(lastTime - 5, lastTime)，而不是把全部历史点都丢进去。否则内存占用会不断上涨，曲线最终会变成一根“毛线”。

3.3 从时域到频域：用kissfft做FFT

时域图转换成频域图，最近很多人在搜索“Qt qcustomplot kissfft时域到频域波形”，我在这套平台里也是用kissfft实现。kissfft是一个轻量级开源FFT库，不需要Qt组件，源文件很少，适合嵌入到桌面项目里。

为什么不用自己手写FFT？FFT的问题在于点很大的时候，编程复杂度会明显上升，使用第三方库更稳。kissfft的接口也简单：一句kiss_fft_alloc分配上下文，执行变换，最后释放。

要把时域信号转成频域谱线，基本步骤是：取一段采样序列，做加窗处理，然后执行FFT，对前一半频点计算幅值，再换算成频率轴。

我使用的简化实现如下：

cpp复制#include "kiss_fft.h"
#include <cmath>

void fftFromTime(const QVector<double>& timeData,
                 double sampleRate,
                 QVector<double>& freqAxis,
                 QVector<double>& magAxis) {
    int n = timeData.size();
    int halfN = n / 2;

    kiss_fft_cfg cfg = kiss_fft_alloc(n, 0, nullptr, nullptr);
    std::vector<kiss_fft_cpx> in(n);
    std::vector<kiss_fft_cpx> out(n);

    for (int i = 0; i < n; ++i) {
        // 汉宁窗，减少频谱泄漏
        double window = 0.5 * (1.0 - cos(2.0 * M_PI * i / (n - 1)));
        in[i].r = timeData[i] * window;
        in[i].i = 0;
    }

    kiss_fft(cfg, in.data(), out.data());
    kiss_fft_free(cfg);

    freqAxis.clear();
    magAxis.clear();

    double df = sampleRate / n;
    for (int i = 0; i < halfN; ++i) {
        freqAxis.push_back(i * df);
        double re = out[i].r / n;
        double im = out[i].i / n;
        double mag = 2.0 * std::sqrt(re * re + im * im);
        magAxis.push_back(mag);
    }
}

这里补充一个容易懵的点：FFT结果是复数数组，第0个元素是直流分量，第1到第n/2-1个元素对应的是正频率分量。幅值计算时，除以n是FFT归一化的常见做法，然后再乘以2，是因为把单边频谱的负频率能量叠加到正频率上。直流分量本身不需要乘2，所以有些人实现里会单独再除以2。

汉宁窗是为了抑制频谱泄漏。直接截断一段时域信号来做FFT，在频域上会出现很多旁瓣，看起来像在真实频率附近多了很多毛刺。加上汉宁窗后，对正弦波信号的频谱更干净。代价是幅值会比不加窗时偏小，如果是做精确幅值分析还要再乘一个恢复系数。

3.4 把频域数据绘制到QCustomPlot

频域图绘制和时域图唯一的区别在于xAxis坐标不再是时间，而是频率。直接把上面的freqAxis和magAxis设置到第二条曲线即可：

cpp复制ui->freqPlot->addGraph();
ui->freqPlot->xAxis->setLabel("频率/Hz");
ui->freqPlot->yAxis->setLabel("幅值");
ui->freqPlot->graph(0)->setData(freqAxis, magAxis);
ui->freqPlot->xAxis->setRange(0, sampleRate / 2);
ui->freqPlot->yAxis->setRange(0, maxMag * 1.1);
ui->freqPlot->replot();

横轴范围上限是采样率的一半，也就是奈奎斯特频率。假设采样率是1000Hz，那么理论上只能分析到500Hz以内的频率分量，超过500Hz的信号会出现混叠。很多刚接触FFT的人会问：我采集卡明明是1000Hz采样，为什么波形图里看不到60Hz的工频干扰，因为设备端已经有过低通滤波或者采样率不够造成混叠。

如果平台统一使用QCustomPlot，时域图和频域图可以做成两个显示页签，共用同一份采样数据源。采样线程每积累够一个窗口长度，就触发一次FFT计算，这样频域图也能按固定周期刷新。

4. Qt环境搭建和发布现场：把平台从开发机搬到其他电脑

4.1 Windows机器上Qt 5.15.2怎么装

这套源码我推荐直接使用Qt 5.15.2，因为社区资料多、各种第三方控件兼容性也好。装Qt时，我建议不要贪多，只勾选你实际用得到的组件：

Qt 5.15.2 的 MSVC 2019 64-bit，配合Visual Studio 2019开发
或者 Qt 5.15.2 的 MinGW 8.1 64-bit，配合Qt Creator直接编译
如果要用到串口、网络这些模块，默认都在Qt SerialPort和Qt Network里，不需要额外勾选，但需要确认你已经安装了对应套件

如果只是想快速跑源码，MinGW套件会更省心，因为不需要另外装VS，Qt Creator自带编译器和调试器。但如果你后续要接Halcon、OpenCV或其他C++库，很多预编译库是配合MSVC发布的，直接使用MSVC套件会少很多ABI不兼容的麻烦。

4.2 最常见的启动崩溃：“no Qt platform plugin could be initialized”

发布Qt程序到另一台电脑时，一个高频报错就是Windows下运行exe弹出：

code复制This application failed to start because no Qt platform plugin could be initialized.
Reinstalling the application may fix this problem.

这个问题几乎可以断定是Qt的platforms插件没有随程序一起发布。你在开发机上能跑，是因为Qt安装目录里有plugins/platforms/qwindows.dll；换到没有Qt环境的电脑上，系统找不到这个插件就罢工了。

解决办法很简单：在Qt命令行工具里执行发布命令，比如MSVC套件可以使用windeployqt：

bash复制windeployqt.exe MyIotPlatform.exe

它会自动把需要的Qt模块、运行库和plugins目录复制到exe所在目录。执行完后务必检查exe同级目录下是否存在plugins/platforms/qwindows.dll。如果没有，就手动从Qt安装目录复制整个platforms文件夹过来。

4.3 Linux上碰到“qxcbconnection failed”怎么办

Linux下跑Qt程序，如果是在服务器或者远程终端环境启动带界面的程序，经常见到这类提示：

code复制qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
qxcbconnection: failed to initialize xrandr
Qt: xkeyboard extension not present

这个报错的出现原因是：xcb插件依赖的一些系统库缺失，或者当前SSH会话没有有效的X11 DISPLAY环境变量。如果程序只是需要跑数据采集逻辑，界面可以暂时不需要，那最简单的办法是使用Qt的offscreen平台插件：

bash复制./IotPlatform -platform offscreen

如果你确实需要远程图形界面，可以检查系统是否安装了libxcb相关库，比如libxcb-xinerama、libxcb-randr、libxkbcommon-x11。这个报错很多情况下不是Qt本身的问题，而是基础图形库没装全。

我的经验是：平台代码里不要硬编码平台插件名，最好在启动脚本里做一次平台参数探测，这样工程可以同时适配Windows和Linux。

5. 设备数据上云：HTTP POST上报里的坑与对策

5.1 用QNetworkAccessManager上报JSON数据

很多工厂或园区项目，除了Qt现场平台显示，还要把数据同步给Web端管理后台。Qt平台这时候就充当边缘采集和转发节点。实现设备数据上报最直接的方式就是HTTP POST。

下面是一段调试可用的代码：

cpp复制#include <QNetworkAccessManager>
#include <QNetworkRequest>
#include <QNetworkReply>
#include <QJsonDocument>
#include <QJsonObject>

void IotReporter::uploadDeviceData(const QString& deviceId, double value) {
    QNetworkAccessManager* manager = new QNetworkAccessManager(this);
    QNetworkRequest request(QUrl("http://192.168.1.100:8080/api/device/report"));

    request.setHeader(QNetworkRequest::ContentTypeHeader, "application/json");

    QJsonObject payload;
    payload["deviceId"] = deviceId;
    payload["value"] = value;
    payload["timestamp"] = QDateTime::currentDateTime().toString(Qt::ISODate);

    QNetworkReply* reply = manager->post(
        request, QJsonDocument(payload).toJson(QJsonDocument::Compact));

    connect(reply, &QNetworkReply::finished, this, [reply, manager]() {
        if (reply->error() != QNetworkReply::NoError) {
            qWarning() << "上报失败:" << reply->errorString();
        } else {
            qDebug() << "上报结果:" << reply->readAll();
        }
        reply->deleteLater();
        manager->deleteLater();
    });
}

QNetworkAccessManager最好在程序开始时创建为一个长生命周期对象，不要每次都new一个新的。因为每个manager都有自己的连接缓存和DNS缓存，频繁创建和销毁反而会导致资源浪费。

5.2 “Qt post请求无法获取”服务器收不到参数的原因

我用实际情况说明，报这个错时先别怀疑Qt本身，多半是请求格式和服务端解析不一致。常见的两种情况：

第一种情况是服务端只支持表单格式，而Qt侧发送了JSON。你需要确认服务端接口文档要求的是application/json还是application/x-www-form-urlencoded。如果接口是别人用的一种常见的Web框架写的，前几行代码通常会调用request.get_json()这类方法，那么必须发JSON，如果手滑用了query string或者form格式，服务端打印出的request体是空。

第二种情况是API地址反斜杠或者端口错了。Qt post请求无法获取，不要一直盯着代码看。我的排查习惯是：先用Postman或者curl发一遍同样请求，如果能通，再回来查Qt代码；如果curl都不通，那就是接口地址或者服务端挂了。

Linux下可以用命令行快速模拟：

bash复制curl -X POST "http://127.0.0.1:8080/api/device/report" \
     -H "Content-Type: application/json" \
     -d '{"deviceId":"dev001","value":23.5}'

在代码里加日志，输出QNetworkReply->errorString以及HTTP状态码，也是一个很有效的排查手段。有一次我的程序报错是HTTP 401，看起来像“服务器拒绝”，实际上是服务端要求头里带Token，我忘加了，跟Qt完全无关。

5.3 Qt平台与微信通知联动

从热搜词里能看到“ESP8266如何实现物联网微信通知”这类需求，实际业务里很多小项目确实希望设备告警时，能直接把消息推到微信，而不是操作员死盯着屏幕。

如果在Qt层面做微信通知，常规思路是使用第三方推送服务的HTTP API接口，例如“企业微信机器人”或“微信测试号”这类产品。Qt平台只需要在阈值告警时，发起一个HTTP POST请求，把告警标题和设备信息发过去。具体接口使用各家服务商的文档，Qt侧代码和上面的上报逻辑是一致的。

这里有个经验：告警推送一定要做“防抖”和“离线缓存”。设备刚上线时数据抖动频繁，可能一秒钟触发好几次告警，如果不做防抖，微信会被连续刷屏。我在源码里加了一个简单的规则：同一个设备同一告警类型，在5分钟内重复触发不重复推送，只更新时间戳。这样的告警记录在Web后台看也是一条合并记录，不会把数据库灌爆。

6. 平台运行中的高频问题排查速查表

为了让文章更实用，我将项目测试阶段遇到的高频问题整理成一个速查表，每一项都是我在实际操作中遇到过的场景：

现象	可能原因	快速解决
串口能打开但收不到数据	波特率/校验位错、设备没发数据、串口被占用	QSerialPortInfo查看可用串口；用串口调试助手对比
界面曲线不刷新	数据信号没连接、UI线程阻塞、定时器没启动	在数据接收处加qDebug；确认生产者/消费者线程
FFT频域横轴不正确	sampleRate参数错误、FFT点数对应频率计算错误	确认采样率，避免偏差：df = sampleRate / N
频域图峰值不明显	没有加窗、信号太弱、频谱泄漏	使用汉宁窗，确认幅值换算
Windows部署后缺少插件	没执行windeployqt	在exe目录补platforms/qwindows.dll
Linux远程启动没有界面	DISPLAY未设置或xcb库缺失	使用-offscreen或在有桌面的会话中运行
HTTP上报无响应	服务端地址不通、Content-Type错误	先用curl测试，再对比Qt请求头
多设备数据互相串	协议中没有设备ID或者设备ID解析错误	在协议帧里打印原始hex，逐一核对

7. 源码二次开发的几条实战心得

完成这套Qt物联网综合管理平台的源码整理后，我从自己的角度总结一些问题。

第一，数据监控模块里一定要有统一的数据缓冲。无论是串口还是网络，凡是“一会儿来一批”的数据，都不要直接丢给界面。先把解析结果放到一个按设备ID和通道号组织的Map里，模型层有清晰的数据结构，画图和存数据库都只是消费这份数据，代码会清爽很多。

第二，QCustomPlot的性能上限比很多人想象中高，但前提是不要在主线程做高频replot。结合实际测试，10个通道、每个通道刷新频率10Hz时，QCustomPlot完全扛得住；但如果你在100ms定时器里对每一张图都执行replot，CPU占用率会很难看。比较稳妥的做法是只重绘当前可见页面，数据缓存好以后切到新页签时再全量刷新。

第三，FFT显示最好独立于时域图。时域数据是连续追加的，频域数据是按窗口计算的，两者的刷新节奏天然不一致。把“采样点数”和“FFT窗口大小”设计成可配置项，比写死一个1024要灵活得多。我在这套源码里把FFT点数做成配置，支持256、512、1024、2048四档，调试现场时非常管用。很多振动监测项目需要分析低频成分，点数不够就看不出来，但点数增加又会产生更高的延迟，需要现场按业务去调。

踩过几次坑之后，我对0.2.1这套源码最大的体会是：技术难点并不在单个点上面，串口解析有套路、FFT有现成库、QCustomPlot有大量示例，真正难的是把这些环节按清晰的数据流串起来。如果你现在也准备在自己的Qt项目里做一个类似的设备监控模块，我的建议是先拿一台设备，从“串口接收原始十六进制数据”开始，确认一帧数据能正确解析；再把它显示到QCustomPlot上；确认时域图和频域图都正常后，再逐步加入数据库、网络上报、多设备管理。先把最小闭环跑通，再去套高大上的平台框架，比从大框架往底层补要顺得多。