Qt大容量数据处理内存占用过高崩溃的优化方案

内存爆炸的核心原因是存储载体选型错误：QTreeWidgetItem是UI组件类，单实例自带Qt元对象开销、父子节点指针、UI渲染缓存、属性表等一堆和纯数据存储无关的冗余，单条item的内存占用是原始行数据的10~20倍属于正常水平。4个总大小2GB的文件全量生成item存下来，占几GB内存崩溃是必然结果。

核心思路是数据和UI完全分离，绝对不要用UI组件当数据存储容器，三层改造完内存占用能降到原方案的1/10以下：

1. 解析层：只存轻量纯数据，预生成查询索引 #

• 解析文件阶段完全不要创建任何QTreeWidgetItem，自定义一个无额外开销的纯结构体存单行数据即可，示例：

// 纯数据结构，不带任何Qt UI相关的父类，开销极低
struct DataRow {
    qint64 id;
    qint64 timestamp; // 时间戳直接转64位整数存储，不要存字符串
    QString field1;
    QString field2;
    double field3; // 数值类字段直接转对应数值类型，不要全存字符串
    double field4;
};

• 解析完的行数据存在QVector<DataRow>中，比QList内存连续性更好，遍历速度更快，几乎无额外冗余。
• 额外建一个时间戳查询索引：维护一个QVector<QPair<qint64, int>>，每个元素存「行时间戳、对应行在DataRow数组中的下标」，所有行解析完成后对这个索引按时间戳排序。后续要查指定时间区间的数据，直接在索引上做二分查找，O(logn)复杂度就能拿到目标行的下标范围，不用全量遍历数据。

这一步改造完，总大小2GB的原始文件，纯数据加载进内存大概只占600~800MB，比原全量存QTreeWidgetItem的方案内存占用低一个量级。

2. UI层：懒加载展示，永远只创建视口内需要的Item #

• 绝对不要把所有数据对应的Item全挂到QTreeWidget上，这个控件本身就是为小批量层级数据设计的，加载超过1万条就会出现明显卡顿，更别说全量加载百万、千万级数据。
• 懒加载逻辑很简单：初始只创建当前视口能容纳的几十条数据对应的QTreeWidgetItem，用户拖动滚动条时，实时计算当前可视区域对应的行范围，临时创建需要展示的Item，同时把滚出视口、暂时不可见的Item直接销毁释放内存。
• 嫌手动写滚动监听、Item复用逻辑麻烦的话，直接把QTreeWidget换成QTreeView，配合自定义继承QAbstractItemModel的模型类实现数据对接即可。Model层只返回View当前请求的行数据，View层自带Item复用和缓存机制，哪怕底层数据源有几千万条，UI层的内存占用永远稳定在几MB级别。

3. 超大数据量兜底：磁盘索引+内存映射 #

如果单文件行数过千万，按上面的方案全量存纯数据内存还是紧张，就不要把所有行数据加载进内存：

• 预扫描文件阶段，只把每一行的「时间戳、该行在源文件中的字节偏移量」存到内存索引里，索引全是64位整数，1千万行也就占160MB左右，内存压力极小。
• 需要查询指定时间区间的数据时，先通过二分查找在索引上拿到目标行对应的文件偏移位置，再用QFile::map做内存映射，只读取、解析当前需要访问的分段数据，不需要访问的内容全留在磁盘上，完全不占运行内存。

• 所有数值类型字段（id、时间戳、数值类的field）绝对不要存成字符串，转成对应数值类型存储，内存占用能差3~5倍，查询、计算速度也会快很多。
• 存在大量重复字符串值的字段，可以单独做简单的字符串池，重复字符串只存一份，进一步压缩内存占用。
• 永远记住：Qt的QTreeWidget、QTableWidget这类基于Item的便捷控件，只适合小数据量场景，大数据量场景一定要用Model/View架构分离数据和UI。

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