企业官网建设流程全解析

简介：MA_V1.02是一款基于Qt框架开发的多道数据分析软件工程包，面向需要处理多通道信号或实验数据的科研人员、工程技术人员以及Qt初学者。软件功能覆盖数据导入、预处理、统计分析、可视化、实时分析和结果导出，适用于科学计算、物联网数据收集与远程监控等场景。压缩包共40个文件，大小约73KB，内容以cpp和h源码为主，搭配6个ui界面文件、qrc资源文件以及大量ico、png图标，构成一套可编译运行的完整Qt工程。工程包含主窗口、连接配置、显示绘图、测试与设置等功能模块，界面、逻辑与资源分离，便于直接运行和二次开发。该资源已有300人学习下载。通过源码可学习到Qt多窗口协作、信号槽通信、事件驱动与多线程处理等核心机制，以及多道数据的组织与展示思路，适用于快速搭建自有分析工具或嵌入科研项目。

1. MA_V1.02 多道数据分析软件：拿到谱数据后，Qt 端第一件事不是画图

如果你手里接过一台多道分析仪（MCA），或者要维护一套叫 MA_V1.02 的 QT 数据分析软件，第一件该搞清楚的事不是界面好不好看，而是谱数据到底怎么进内存、怎么保证不卡。这类软件的核心不是“用 Qt 画一条谱线”，而是把探测器送来的几千到几万道计数，在百毫秒级内完成读取、刷新、寻峰和能量刻度。多道数据分析软件的典型使用者是核物理实验、环境辐射监测、X 射线荧光分析这几个方向的人，他们手里的数据天然是离散整数数组，对实时性和准确性要求都不低。这篇文章按我自己做这类软件的路径，把数据模型、表格性能、谱图绘制、寻峰刻度和发布排错一次讲完。

2. 多道数据从硬件进内存：把 4096 道计数装进 SpectrumFrame 的读写链路

2.1 道址、计数与 ADC 位数：多道数据为什么本质上是个整数数组

多道分析器的前端链路是：探测器输出信号经前置放大和主放大器整形后，进入 ADC。ADC 把每个脉冲的峰值电压量化为一个整数，这个整数就是“道址”，落在某一道址的事件会让对应位置的计数器加 1。ADC 位数直接决定道数，12 位 ADC 对应 4096 道，14 位对应 16384 道。所以一帧谱数据就是一个长度等于道数的无符号整数数组，数组下标是道址，数组值是计数。

这个模型决定了后面所有代码怎么写：数据结构用连续内存的 QVector 而不是 QList，读文件按道址顺序填数组，画图时横轴是道址、纵轴是计数。道址本身不是能量，能量要靠标准峰刻度换算，这个换算关系一般是一次线性或二次多项式，后面单独讲。先记住一句话：多道数据的本质是“一维整数计数数组”，所有性能问题和算法问题都从这个本质展开。

2.2 SpectrumFrame 结构体与生产者消费者线程模型

硬件采集是高频的，UI 刷新不能跟着硬件节奏走，否则界面直接卡死。我一般会定义一个 SpectrumFrame 结构体，把一帧谱数据的所有信息装在一起：

// SpectrumFrame.h —— 一帧多道谱数据的标准结构 struct SpectrumFrame { qint32 channels = 0; // 道数，常见 4096/8192/16384 QVector<quint32> counts; // 每道计数，长度必须等于 channels double liveTime = 0.0; // 活时间：ADC 开门测量的时间 double realTime = 0.0; // 实时间：包含死时间的墙钟时间 quint64 frameIndex = 0; // 帧序号，用于排查数据乱序 };

用 quint32 存计数是因为单道计数可能越过 65535，用 int 又浪费一半空间；道址数量动辄上万，能省内存就省。channels 和 counts.size() 的一致性很重要，我在 appendFrame 里会加断言，不一致直接报警，避免后续寻峰越界。

有了结构体，采集线程和 UI 线程之间用生产者消费者模型。采集线程从硬件读帧，UI 线程消费帧刷新界面。这里有个关键参数：跨线程传帧时不要传整个结构体，几 MB 的数组在队列连接里会深拷贝，卡的是 UI 线程的事件循环。常见做法是传 QSharedPointer 指针：

// 采集线程：模拟从硬件读取谱帧并发出 class Acquirer : public QObject { Q_OBJECT public slots: void startPolling() { while (!QThread::currentThread()->isInterruptionRequested()) { SpectrumFrame frame = readFromDevice(); // 从接口读一帧 emit frameReady(QSharedPointer<SpectrumFrame>( new SpectrumFrame(std::move(frame)))); // 只传指针 } } signals: void frameReady(QSharedPointer<SpectrumFrame> frame); }; // 主线程：moveToThread 后建立队列连接 auto thread = new QThread; auto acq = new Acquirer; acq->moveToThread(thread); connect(thread, &QThread::started, acq, &Acquirer::startPolling); connect(acq, &Acquirer::frameReady, model, &SpectrumTableModel::appendFrame, Qt::QueuedConnection); connect(acq, &Acquirer::frameReady, plotWidget, &SpectrumPlot::appendFrame, Qt::QueuedConnection);

关键点是 moveToThread 之后，Acquirer 的槽函数跑在子线程；信号槽默认连接方式会按线程自动变成队列连接。shared pointer 把一帧数据的所有权交给最后一个消费者，Qt 的队列连接对 QSharedPointer 有内置注册，不需要额外 qRegisterMetaType。这样 UI 线程拿到的只是指针拷贝，一帧几 MB 的数组不会被反复复制。

2.3 SPE 文件解析：$CHAN 与 $DATA 头格式里的字节序陷阱

除了实时采集，软件还要能打开历史谱文件。多道领域最常见的落盘格式是 SPE，Canberra 系设备导出的文本谱格式。它的骨架是：若干以 $ 开头、冒号分隔的头部字段，遇到 $DATA: 之后就是每道计数的数据区。我通常解析这几个字段：

解析代码不算复杂，坑在格式变体：

bool loadSpeFile(const QString &path, QVector<quint32> &counts, double *live, double *real) { QFile f(path); if (!f.open(QIODevice::ReadOnly | QIODevice::Text)) return false; QTextStream in(&f); bool inData = false; int expectChannels = 0; counts.clear(); while (!in.atEnd()) { QString line = in.readLine(); if (line.startsWith("$CHAN:")) { expectChannels = line.mid(6).trimmed().toInt(); } else if (line.startsWith("$MEAS_TIM:")) { QStringList t = line.mid(10).trimmed().split('/'); if (t.size() == 2) { *live = t[0].toDouble(); *real = t[1].toDouble(); } } else if (line.trimmed() == "$DATA:") { inData = true; } else if (inData) { const QStringList parts = line.split(QRegularExpression("[\\s,;]+"), Qt::SkipEmptyParts); for (const QString &p : parts) counts.append(p.toUInt()); } } if (expectChannels > 0 && counts.size() != expectChannels) qWarning() << "SPE 道数不匹配，期望" << expectChannels << "实际" << counts.size(); return counts.size() > 0; }

这里有两个容易翻车的地方。一是分隔符，有的设备导出的数据区用逗号，有的用空格，还有的用分号，所以我用正则把所有分隔符统一处理，Qt::SkipEmptyParts 去掉连续分隔产生的空串。二是字节序，SPE 也有二进制变体，数据区里的 32 位整数是大端序存的，如果按小端读，你会看到 4096 道计数变成几十亿的乱数；判断方法是先读前几行文本头，如果开头不是 $SPEC_ID 而是乱码，就要按二进制分支处理。这个分支我建议单独写成 readSpeBinary()，别和文本解析混在一个函数里，否则后面加格式支持时改起来很费劲。

3. 谱线表格不卡顿的写法：QTableView + QAbstractTableModel 替换 QTableWidget

3.1 QTableWidget 在 16384 个单元格上为什么会翻车

多道软件常有一个“谱数据表格页”，展示道址和计数两列，供人逐道核对。很多初版实现图省事用 QTableWidget，循环填充 QTableWidgetItem。问题很快暴露：8192 道的数据就是 8192 行加 2 列，等于 16384 个 QTableWidgetItem 对象，每个 item 都是一个 QObject，光创建就要几十毫秒。更糟的是滚动时这些对象全部驻留在内存里，占着资源不说，任何一次全表更新都伴随大量对象析构和重建，UI 线程直接被拖到几百毫秒的卡顿。

QTableWidget 是“数据在 item 里”的模型，QTableView + QAbstractTableModel 是“数据在外部数组里、视图按需取数”的模型。多道谱数据天然是连续数组，用后者几乎是零成本改造。视图在滚动时只会请求当前可见区域的 index，你只需要在 data() 里从 QVector 取值，不用创建任何 QObject。

3.2 QAbstractTableModel 最小实现：rowCount、columnCount 与 data

自定义模型至少要重写 rowCount、columnCount 和 data 三个函数。按需取数是这套机制的灵魂：

class SpectrumTableModel : public QAbstractTableModel { Q_OBJECT public: explicit SpectrumTableModel(QObject *parent = nullptr) : QAbstractTableModel(parent), m_loaded(0) {} void loadData(const QVector<quint32> &counts) { beginResetModel(); m_counts = counts; m_loaded = 0; endResetModel(); fetchMore(QModelIndex()); // 先加载第一段 } int rowCount(const QModelIndex &parent = QModelIndex()) const override { return parent.isValid() ? 0 : m_loaded; } int columnCount(const QModelIndex &parent = QModelIndex()) const override { return parent.isValid() ? 0 : 2; // 两列：道址、计数 } QVariant data(const QModelIndex &idx, int role) const override { if (!idx.isValid()) return {}; const int ch = idx.row(); if (role == Qt::DisplayRole) return idx.column() == 0 ? ch : m_counts.at(ch); if (role == Qt::TextAlignmentRole) return Qt::AlignRight | Qt::AlignVCenter; if (role == Qt::BackgroundRole && ch >= m_roiStart && ch <= m_roiEnd) return QColor(255, 228, 181); // ROI 区间高亮 return {}; } // 省略 canFetchMore / fetchMore 实现，见 3.3 private: QVector<quint32> m_counts; int m_loaded = 0; int m_roiStart = -1; int m_roiEnd = -1; };

道址列直接返回行号，计数列返回数组值，不要在 data() 里做文件读取或耗时的类型转换。之前有人把 double 转字符串放在 data() 里，滚动一次就吃满一个核，转字符串要在数据准备阶段完成或直接用 QString::number 缓存。还要注意 rowCount 返回 m_loaded 而不是 m_counts.size()，这个细节决定了分段加载是否生效，后面解释。

3.3 分段加载与行高优化：fetchMore 和 setUniformRowHeights 的参数

QAbstractTableModel 有个默认行为：canFetchMore 返回 false，视图一次性认为所有行都是可用的，QTableView 为了计算滚动条比例会反复调用 data() 问高度和内容，8192 行就是 8192 次取数，还是卡。正确做法是让模型支持增量取数：

bool canFetchMore(const QModelIndex &parent) const override { return parent.isValid() ? false : (m_loaded < m_counts.size()); } void fetchMore(const QModelIndex &parent) override { if (parent.isValid()) return; int remainder = m_counts.size() - m_loaded; int toFetch = qMin(1024, remainder); if (toFetch <= 0) return; beginInsertRows(QModelIndex(), m_loaded, m_loaded + toFetch - 1); m_loaded += toFetch; endInsertRows(); }

1024 是我常用的分页大小，对 4096 道数据分 4 次加载，对 16384 道分 16 次，每次插入行数都在视图可接受范围。beginInsertRows 的父索引必须是 QModelIndex()，也就是根节点，写错的话视图不响应插入，表格空白。另外在 view 上设置：

tableView->setUniformRowHeights(true);

行高一致时 QTableView 不走“逐行询问高度”的慢路径，滚动计算只做一次，这个开关对几千行表格提升非常明显，代价是不能再支持不同行高。如果你未来要按计数值画行内背景条，uniform 行高也不受影响，背景色是 delegate 和 data 层的事。

3.4 表格与绘图联动：用 dataChanged 高亮 ROI 区间

多道软件里，表格和谱图是同一份数据的两张脸，用户在图里框一个峰区，表格里对应道址应该同步高亮。联动用信号槽，但不要动不动就 reset 模型。我一般给模型暴露一个 setRoi 方法：

void setRoi(int start, int end) { m_roiStart = start; m_roiEnd = end; QModelIndex top = index(qMax(0, start), 0); QModelIndex bottom = index(qMin(m_counts.size() - 1, end), 1); emit dataChanged(top, bottom, {Qt::BackgroundRole}); }

只发射受影响区间的 dataChanged，视图只重绘这几行的背景色，滚动位置不跳。如果你用 beginResetModel，表格会退回首屏，用户框完峰找不到自己滚到哪了，这是体验上非常明显的细节。联动时，绘图组件发信号，模型更新，表格和绘图各自响应自己的刷新逻辑，不要让表格直接调用绘图的私有函数，后面加第二个绘图窗口时才不会到处开花。

4. 谱图绘制与感兴趣区分析：QCustomPlot 画谱线、寻峰与净面积计算

4.1 线性轴 vs 对数轴：低能端堆积为什么要把纵轴切到对数

能谱数据的动态范围极大：低能端康普顿平台计数可能到几十万，高能端弱峰可能只有几十个计数。线性纵轴下，弱峰被压在底部完全看不见，这就是为什么所有核谱分析软件都默认给谱线加一个对数纵轴。对数轴也有代价：计数为 0 的道址在数学上没定义，log10(0) 是负无穷，绘制时要么跳过 0 值点，要么把 0 统一映射到纵轴下限 0.5 或 1。

我在实现里选择纵轴下限固定为 1，0 计数的道址自然落在下限线上，视觉上不会产生断崖。如果你要凸显弱峰细节，可以再加一条线性纵轴让用户切换，但默认必须是对数，否则第一屏就把用户劝退了。

4.2 QCustomPlot 最小谱图：setData 与对数坐标参数

QCustomPlot 画谱线比 Qt Charts 更可控，毕竟谱线就是一根折线，不需要饼图柱状图那些重量级组件。最小实现只需要 addGraph、setData 和坐标轴设置：

void SpectrumPlot::showFrame(const QVector<quint32> &counts) { const int n = counts.size(); QVector<double> x(n), y(n); for (int i = 0; i < n; ++i) { x[i] = i; y[i] = counts[i]; } ui->plot->clearGraphs(); ui->plot->addGraph(); ui->plot->graph(0)->setData(x, y); ui->plot->graph(0)->setPen(QPen(QColor(30, 80, 200), 1.0)); ui->plot->xAxis->setLabel(QStringLiteral("道址 (Channel)")); ui->plot->yAxis->setLabel(QStringLiteral("计数 (Counts)")); ui->plot->xAxis->setRange(0, n); ui->plot->yAxis->setScaleType(QCPAxis::stLogarithmic); ui->plot->yAxis->setScaleLogBase(10); ui->plot->yAxis->setRange(1, 100000); // 初始高度，后续按数据自动调 ui->plot->replot(); }

对数轴的三个参数别漏：setScaleType 切到对数、setScaleLogBase 设底数、setRange 下限给正数。有人只切类型不设 base，默认是 10 还好；有人把 range 下限设成 0，QCustomPlot 直接画出一堆 nan。初版可以把 y 轴上限设成一个经验值，比如 100000，后面再根据最大计数调。QCustomPlot 缩放时如果发现曲线贴底，多半是数据里有 0 值且纵轴下限不对，先查 yAxis->range()。

4.3 找峰、ROI 与净峰面积：二阶差分寻峰和线性本底扣除

寻峰算法不要一上来就整高斯拟合，那东西依赖初始参数，拟合不收敛时你根本不知道是峰选错了还是迭代炸了。我先用二阶差分做一个粗筛，把候选峰位找出来，再交给后续拟合：

QVector<int> findPeaks(const QVector<quint32> &c, double k = 2.5) { QVector<int> peaks; const int n = c.size(); for (int i = 2; i < n - 2; ++i) { double d2 = c[i - 1] - 2.0 * c[i] + c[i + 1]; double avg = (c[i - 2] + c[i - 1] + c[i] + c[i + 1] + c[i + 2]) / 5.0; if (d2 < 0 && -d2 > k * std::sqrt(avg)) { peaks.append(i); } } return peaks; }

原理是峰顶处二阶差分明显为负，而统计涨落的二阶差分会围绕 0 波动。阈值系数 k 乘的是局部计数的标准差近似值 sqrt(avg)，这样计数高的区域和计数低的区域用同一把尺子。k 的取值是个经验参数：2.0 偏灵敏，弱峰会冒出来但假峰也多；3.0 偏保守，适合高本底数据；2.5 是多数谱分析软件的默认值。你可以在设置界面暴露这个参数，让用户按谱调，别写死。

框出感兴趣区（ROI）之后算净峰面积，常见的做法是线性本底扣除。假设本底在 ROI 边界间线性变化，总面积减掉梯形本底就是净面积：

quint64 gross = 0; for (int i = roiStart; i <= roiEnd; ++i) gross += c[i]; double bkg = (roiEnd - roiStart + 1.0) * (c[roiStart] + c[roiEnd]) / 2.0; double net = gross - bkg; double sigma = std::sqrt(gross + bkg); // 净面积的统计误差

这个算法的假设是 ROI 两侧边界处没有其他峰的尾巴叠加，边界选在峰脚附近最稳。净面积算完一定要带上统计误差 sigma，报告格式里“净面积 ± 误差”是硬要求，只给一个裸净面积的报告在核测量领域是会被打回来的。本底扣除看着简单，实际是最容易“玄学”的一步：边界选宽了把相邻峰尾巴算进来，选窄了本底估高。我的经验是先用二阶差分定位峰边界点，再向两侧各外扩 2 道作为 ROI，别让用户手工乱圈。

4.4 能量刻度最小二乘：两个标准峰还是全部峰一起拟合

道址到能量的换算一般是一次线性关系，用两个已知能量的标准峰就能定标。但两个峰定标对峰位误差太敏感，任何一个峰位偏 0.3 道，刻度斜率就明显偏。所以我一般收集至少 3 个标准峰做最小二乘拟合，并把残差打出来看：

// 输入：峰位道址数组 peakChs、对应能量数组 peakE（单位 keV） double sx = 0, sy = 0, sxx = 0, sxy = 0; int n = peakChs.size(); for (int i = 0; i < n; ++i) { sx += peakChs[i]; sy += peakE[i]; sxx += peakChs[i] * peakChs[i]; sxy += peakChs[i] * peakE[i]; } double a = (n * sxy - sx * sy) / (n * sxx - sx * sx); double b = (sy - a * sx) / n; // 残差检查：每个峰位的实测能量与拟合能量之差 for (int i = 0; i < n; ++i) { double eFit = a * peakChs[i] + b; qInfo() << "峰" << i << "残差(keV):" << (peakE[i] - eFit); }

峰位道址不要用最大值那个整数道，要用质心法或高斯拟合后的峰位，整数道址在统计涨落影响下会跳 1~2 道，质心法能把峰位精度提回亚道级。残差如果超过 1~2 keV，说明刻度不是线性，需要加二次项。二次拟合用最小二乘正规方程解 3 阶矩阵，或者在 Qt 里调用 QLinearFit？没有现成的，我一般手写一个 3x3 高斯消元，几十行搞定。还有一个易错点：道址在数学上是从 0 开始的整数，但 ADC 的道址中心其实是 ch + 0.5，做精密刻度时用中心值，普通场景忽略影响也不大。

5. 常见问题与避坑指南：dependent 头文件、qpa.plugin 和线程崩溃

5.1 编译期：dependent '......\qt\5.15.2\msvc2019_64\include\qtwidgets' 消失

现象：Qt Creator 构建时直接报:-1: error: dependent '..\..\..\..\..\..\qt\5.15.2\msvc2019_64\include\qtwidgets' does not exist，整个项目一瞬间所有文件都标红。

原因：这个报错几乎都是 Kit 选错导致的。项目里装了两个 Qt 版本，一个 MinGW 一个 MSVC2019_64，当前 Kit 指向的编译器和 Qt 版本不匹配，qmake 生成的 makefile 引用了错误路径。还有一种是 Qt Maintenance Tool 更新后把某个模块移动了位置，老项目里缓存了旧路径。

解决：先确认你给项目选的 Kit，打开“工具 -> 选项 -> Kits”，看编译器、Qt 版本、CMake/qmake 路径三个字段是否指向同一套环境。然后删掉 build 目录里的 shadow build 缓存，重新执行 qmake 再全量构建。如果还报错，打开.pro文件检查有没有多写QT += widgets或漏写，这个依赖头文件路径就是 widgets 模块的头。MSVC2019_64 的 Qt 必须配 MSVC 编译器，不要混 MinGW。

5.2 运行期：qt.qpa.plugin could not find the windows platform plugin

现象：开发环境里跑得好好的 exe，拷到别的机器上双击，弹窗报qt.qpa.plugin: could not find the Qt platform plugin "windows" in ""，程序直接退出。

原因：Qt 程序运行需要 platform 插件，也就是 platforms 目录下的 qwindows.dll。发布时只拷贝了 exe 和 Qt5Core.dll、Qt5Gui.dll 这些主库，漏了插件目录。环境变量 QT_QPA_PLATFORM_PLUGIN_PATH 被外部设置成无效路径也会触发。

解决：不要手动拷 DLL，用 Qt 自带的 windeployqt 工具生成完整发布目录：

windeployqt --release --no-translations --no-system-d3d-compiler .\build\MA_V1.02.exe

跑完检查发布目录里有没有platforms\qwindows.dll，没有就是 windeployqt 没识别到 GUI 模块，确认 exe 路径是否带空格、是否把 release 版的 exe 给了 debug 版工具。程序里也可以在 main 函数最前面加一行 qputenv("QT_QPA_PLATFORM_PLUGIN_PATH", ...) 指定插件绝对路径，但这只是兜底，正确做法还是让发布目录结构完整。

5.3 采集线程崩溃：moveToThread 后的对象生命周期与析构顺序

现象：软件运行几分钟到几十分钟随机崩溃，崩溃栈在 QThread 或信号槽内部，有时候报 pure virtual call，有时候直接 segmentation fault。

原因：两种情况最常见。一是采集线程里的代码直接操作了 UI 对象，比如调 ui->label->setText，跨线程访问 QObject 是非线程安全的，看起来偶尔成功，实际上已经埋雷。二是 QThread 对象在子线程仍在运行时就被析构了，Qt 文档明确警告过这是未定义行为，随机崩溃一点不冤。

解决：采集线程里绝不直接碰 UI，用信号把 QSharedPointer 发回主线程，主线程的槽函数再更新界面。线程析构顺序固定成三步：先 requestInterruption 让采集循环退出，再 quit 退出事件循环，最后 wait 等线程真正结束。我在 MainWindow 的关闭事件里这么写：

void MainWindow::closeEvent(QCloseEvent *e) { m_thread->requestInterruption(); // 1. 让采集循环退出 m_thread->quit(); // 2. 事件循环退出 m_thread->wait(3000); // 3. 等线程结束，超时报错 QMainWindow::closeEvent(e); }

wait 超时参数我给 3000 毫秒，要是采集循环里有阻塞读没及时响应，wait 返回 false，这时候再发警告日志定位。千万别在关闭时直接把 Acquirer delete，那个对象已经 moveToThread 到子线程，应该在子线程退出后通过 deleteLater 清理，否则还是跨线程删除，继续崩。

5.4 double 转字符串与道址越界：4094.999 不是 4095

现象：能量刻度后，某个峰位道址显示成 4094.999，或者程序在counts[ch]处崩溃，报错说下标越界。

原因：道址是整数，但刻度换算(energy - b) / a的结果是 double。浮点数换算出来的 4095.0 可能是 4094.999999999，直接截断成 int 就是 4094，再去访问数组没问题，但显示出来就露馅了。更危险的是有人直接拿这个 double 当数组下标，C++ 隐式转换会再次截断，如果结果是 16384 而数组长度是 16384，越界访问就发生了。

解决：道址和计数走整数通路，只有刻度系数用 double。获取道址统一走：

qint32 ch = qRound(energyToChannel(662.0)); // 662 keV 对应的道址 ui->channelLabel->setText(QStringLiteral("峰位道址: %1").arg(ch));

qRound 是 Qt 的最近取整，0.5 进位，比 static_cast 安全。显示计数不要用QString::number(counts[i])之外再套一层 double，直接丢整数进去。这个问题的根子是数据类型混用，我在代码审查时看到 double 和 qint32 互相赋值就会停下来盯着看三秒。

5.5 表格只显示几十行：fetchMore 没实现导致视图反复取数

现象：QTableView 接上自定义模型后，表格只显示最初几十行，滚动条拉不动，或者能滚但滚动时界面卡到 2 秒才响应。

原因：rowCount 返回全量 8192，但 canFetchMore 没实现或返回 false。视图以为所有行都可用，为了渲染滚动条就去向模型问全部行的高度，每问一行触发一次 data()，UI 线程被几万次调用淹没。而显示几十行是因为视图在可见区域外没有继续请求，或者 fetchMore 里的 beginInsertRows 父索引写错导致插入事件没被视图接收。

解决：按 3.3 节的实现补全 canFetchMore 和 fetchMore，rowCount 返回 m_loaded 而不是总行数；同时确认 beginInsertRows 的第一个参数是 QModelIndex()。做完这两点，再给 view 开 setUniformRowHeights(true)，滚动条计算量从 O(n) 降成 O(1)。检查方法：在 fetchMore 里加一行 qInfo 打印每次加载的行数，滚动表格时应该能看到 1024 行一批地追加，而不是一次性 8192 行。

6. 给 MA_V1.02 做发布体检：windeployqt 之外，再查这三件事

6.1 最小发布目录与运行验证

发布目录不是 exe 加一堆 DLL 就算完。我每次发布前会在一台干净的 Windows 虚拟机里跑一遍，虚拟机里不装 Qt、不装 Visual Studio，exe 能正常启动才算过。重点检查 platforms 目录、styles 目录（qwindowsvistastyle.dll，缺了界面样式会退化到老式风格）、imageformats 目录（加载图标和图片需要）。如果你用了 QCustomPlot，它编译进 exe 不需要额外 DLL，但如果你动态链接了 Qt5PrintSupport，风 deployqt 会自动带，别手动删。最后用进程监控工具看一眼启动时有没有到外部目录找 DLL 的告警。

6.2 用已知谱文件回归寻峰结果

算法改完不能只看效果图，要做回归。我保留了一份标准源测量谱，用 137Cs 的 662 keV 峰做回归基准。每次改完寻峰或刻度代码，跑一遍对比结果：峰位道址误差不能超过 1 道，峰面积相对误差不能超过 1%，FWHM 计算值和上次发布版本差异不能超过 3%。这个对比脚本用 Qt 写的命令行工具就行，输入谱文件路径，输出峰位、面积和 FWHM，再 diff 两个版本的输出。没有基准数据的软件，改算法就是在赌运气，我吃过这个亏，现在基准文件是仓库里的强制门槛。

6.3 定位界面卡顿：QElapsedTimer 找耗时函数

用户说“界面卡”，先别猜。给可疑函数加上计时，比如 data()、寻峰、replot 各包一层 QElapsedTimer：

QElapsedTimer t; t.start(); // 寻峰算法 qInfo() << "findPeaks 耗时(ms):" << t.elapsed();

UI 线程单帧不能超过 16ms，超过就能被感知。如果 data() 超过 1ms，说明里面有隐式转换或重复计算；如果 replot 超过 10ms，考虑降采样绘制，能谱数据几万点画线其实不必每个点都画，可以用 QCustomPlot 的 setData 前做抽稀，只保留 FWHM 窗口内的细节和本地极值点。性能优化要用计时说话，不要拿“感觉”当依据。

6.4 给板卡移植留后路：把采集、算法、UI 三层拆开

我现在的习惯是采集、算法、UI 三层独立编译，采集层只依赖 QtCore，算法层只依赖 QtCore 和 Eigen，UI 层才依赖 QtWidgets/QCustomPlot。这样以后要移植到 Linux 或 arm64 板卡，只需要换采集层的硬件接口，算法和 UI 基本不动。多道数据分析看似是个桌面软件，但很多项目最后都要跑到一体化设备上，把数据来源和算法处理彻底解耦，比提前设计一百个界面功能更值钱。这个拆分如果在 MA_V1.02 早期没做，现在补也不迟，先把 SpectrumFrame 从 UI 依赖里剥出来，再逐步把寻峰和刻度搬进独立静态库。我吃过不拆层的亏，后期每个新需求都在三个文件里改，改完还得全量回归；现在拆开之后，新增硬件支持只用动采集层一个接口，希望帮到你。

本文还有配套的精品资源，点击获取