简介这是一份面向Qt桌面开发者的自定义数据模型实战资源核心是继承QAbstractTableModel实现TableMode模型解决QTableView在加载千万级数据时卡顿、内存占用高的问题。底层采用QVector存储数据尾部追加插入性能与QList相当内存开销也接近适合需要展示海量表格记录的场景。压缩包共49个文件约13.64MB包含8个cpp与5个h源码文件、2个ui界面文件、1个qrc资源文件及vcxproj工程配置另有obj、tlog、pdb等编译中间产物和若干txt测试数据可直接在Visual Studio中打开编译运行。资源附带了从1万到1000万行不等的测试数据文件方便读者实测加载速度与内存表现。目前已有1644人学习下载适合具备一定Qt基础、希望深入理解Model/View架构与大数据量渲染优化的开发者参考借鉴。1. 自定义 TableMode 模型一千万行数据为什么让默认控件直接趴窝很多人第一次把 QTableView 接到一个几十万行的数据源上界面还能勉强滑动一旦数据量冲到一千万行程序启动就卡死滚动条拖一下直接无响应。问题不在 QTableView而在你用了 QStandardItemModel 这类每行都建对象的模型。一千万行意味着上千万个 QStandardItem 实例内存先爆构造时间再爆。真正扛得住大数据的做法是继承 QAbstractTableModel自己实现一个按需取数的自定义数据模型让视图只向你要它当前看得见的那几十行。这篇笔记就围绕这个方向把接口怎么实现、数据怎么按需加载、一千万行怎么不卡、坑在哪一步步讲清楚。适合已经会写 Qt 界面、但被大数据量卡住的开发者。2. 继承 QAbstractTableModel四个必须实现的接口与它们的调用时机2.1 为什么是 QAbstractTableModel 而不是 QStandardItemModelQStandardItemModel 的设计目标是方便它把每个单元格都变成一个 QStandardItem 对象内部还维护树形索引、排序代理等一堆结构。行数少的时候无所谓行数一多光是对象头开销就够呛。一个 QStandardItem 加上它持有的 QVariant、字符串、父子指针保守估计上百字节一千万行乘以列数内存直接以 GB 计而且构造过程是同步的主线程必然卡死。QAbstractTableModel 是抽象基类它不替你存任何数据只定义了一套视图问、你答的协议。视图在绘制时只会调用 rowCount、columnCount、data 这几个接口而且只针对当前可见区域和少量预取区域。也就是说哪怕你背后挂着一千万行视图一次真正问你的也就几十到几百行。这就是大数据量下必须走自定义模型的根本原因。选型上还有一层如果你的数据是二维表、行列固定用 QAbstractTableModel如果是树形结构用 QAbstractItemModel。标题说的是表格所以锁定 QAbstractTableModel。2.2 四个核心接口的最小实现下面是一个能跑起来的最小骨架先让它能显示数据再谈性能。from PySide6.QtCore import QAbstractTableModel, QModelIndex, Qt class BigTableModel(QAbstractTableModel): def __init__(self, headers, total_rows, parentNone): super().__init__(parent) self._headers headers # 列名列表 self._total_rows total_rows # 总行数一千万就填 10_000_000 self._cache {} # 行缓存后面章节细讲 def rowCount(self, parentQModelIndex()): # 视图问你有多少行直接返回总数不要在这里遍历数据 if parent.isValid(): return 0 return self._total_rows def columnCount(self, parentQModelIndex()): if parent.isValid(): return 0 return len(self._headers) def data(self, index, roleQt.DisplayRole): # 视图只为可见单元格调用这里是性能关键路径 if not index.isValid(): return None if role Qt.DisplayRole: row, col index.row(), index.column() return self._get_cell(row, col) return None def headerData(self, section, orientation, roleQt.DisplayRole): if role ! Qt.DisplayRole: return None if orientation Qt.Horizontal: return self._headers[section] return str(section 1) def _get_cell(self, row, col): # 占位真实实现里从缓存或数据源取 return fr{row}c{col}逻辑说明rowCount 和 columnCount 是视图用来确定滚动范围和信息量的必须 O(1) 返回绝不能在里面做任何遍历或查询。data 是绘制时高频调用的只处理 DisplayRole 这类必要角色其他角色快速返回 None。headerData 负责表头文字行号直接用 section1 生成不需要额外存储。参数说明total_rows 用整数存总行数一千万在 64 位 Python 里没问题headers 是列名列表长度即列数parent 参数在表格模型里通常无效返回 0 即可这是 Qt 的约定别在这里纠结。2.3 角色role处理别在 data 里做重活data 接口的 role 参数决定了视图这次要什么。常见的有 DisplayRole显示文字、TextAlignmentRole对齐、BackgroundRole背景色、ForegroundRole前景色、ToolTipRole提示。新手容易犯的错是在 data 里对每个 role 都做一次数据查询导致同一个单元格被反复取数。正确做法是把取数逻辑收敛到一次按 role 分发。比如先判断 role 是否在需要数据的集合里不在就直接返回 None。对于一千万行的场景DisplayRole 是绝对主力其他角色能省则省。如果确实要按行着色也要保证取数走缓存不能每次都回源。def data(self, index, roleQt.DisplayRole): if not index.isValid(): return None if role Qt.DisplayRole: return self._get_cell(index.row(), index.column()) if role Qt.TextAlignmentRole: return int(Qt.AlignVCenter | Qt.AlignLeft) return None这样写视图问对齐时不会触发取数问显示时才取职责清晰。3. 一千万行不卡的取数策略缓存、分页与懒加载怎么配合3.1 行缓存用 LRU 把可见区域附近的行留住视图滚动时同一行可能被反复请求重绘、悬停、选中都会触发。如果每次都回源查询一千万行的数据源再快也扛不住。解决办法是加一层行缓存键是行号值是这一行的数据列表或元组。缓存不能无限大否则又变成全量加载所以用 LRU 策略只保留最近访问的若干行。from collections import OrderedDict class BigTableModel(QAbstractTableModel): def __init__(self, headers, total_rows, source, cache_size2000, parentNone): super().__init__(parent) self._headers headers self._total_rows total_rows self._source source # 数据源对象负责真正取数 self._cache_size cache_size self._cache OrderedDict() def _get_row(self, row): if row in self._cache: self._cache.move_to_end(row) # 命中就移到末尾标记为最近使用 return self._cache[row] data self._source.fetch_row(row) # 回源取一整行 self._cache[row] data if len(self._cache) self._cache_size: self._cache.popitem(lastFalse) # 淘汰最久未用的行 return data def _get_cell(self, row, col): return self._get_row(row)[col]逻辑说明OrderedDict 天然支持按插入顺序淘汰move_to_end 把命中行标记为最新popitem(lastFalse) 淘汰最旧。cache_size 取 2000 左右足够覆盖一屏可见行加上滚动预取内存占用可控。参数说明cache_size 不是越大越好。一千万行里你真正频繁访问的永远是当前视口附近缓存开到几万只会增加淘汰开销和内存。2000 到 5000 是常见区间具体看列宽和单行数据大小。3.2 数据源分页把取一行变成取一页如果数据存在数据库或大文件里逐行查询一千万次是不现实的。常见做法是按页取比如一次取 1000 行缓存里存的是页行号先换算成页号和页内偏移。class PagedSource: def __init__(self, page_size1000): self.page_size page_size self._pages {} # 页号 - 该页的行列表 def fetch_row(self, row): page_no row // self.page_size offset row % self.page_size if page_no not in self._pages: self._pages[page_no] self._load_page(page_no) return self._pages[page_no][offset] def _load_page(self, page_no): start page_no * self.page_size # 真实实现SELECT ... LIMIT page_size OFFSET start # 或从内存映射文件按偏移读取 return [[fr{r}c{c} for c in range(8)] for r in range(start, start self.page_size)]逻辑说明行号到页号的换算是整除和取模O(1)。页缓存和行缓存可以叠加也可以只保留页缓存让行缓存退化成页内索引。分页的好处是回源次数从行数降到页数一千万行按 1000 一页也只有一万页实际访问的页远小于这个数。参数说明page_size 太小回源频繁太大单次加载慢且内存浪费。1000 到 5000 是常见选择配合数据库的 LIMIT/OFFSET 或文件偏移读取。3.3 懒加载与占位先给视图一个正在加载的答复如果某一页数据加载需要时间比如走网络或磁盘不能在 data 里同步阻塞否则界面还是会卡。做法是 data 先返回占位符同时触发异步加载加载完成后用 dataChanged 通知视图刷新对应区域。def data(self, index, roleQt.DisplayRole): if role ! Qt.DisplayRole or not index.isValid(): return None row, col index.row(), index.column() if not self._source.has_row(row): self._source.request_row(row) # 触发异步加载不阻塞 return … # 占位符 return self._get_cell(row, col)逻辑说明has_row 判断数据是否已就绪未就绪就发起请求并返回占位。异步加载完成后在回调里发出 dataChanged(topLeft, bottomRight) 信号视图会重新调用 data 取到真实值。参数说明占位符用…或空字符串都行关键是别让 data 阻塞。异步加载的线程模型可以用 QThread 或线程池注意跨线程更新模型必须回到主线程发信号。4. 避坑与排查自定义模型最容易翻车的五个地方4.1 现象滚动到后面行显示空白或错位原因rowCount 返回的总行数和数据源实际能提供的行数不一致或者分页换算时边界算错最后一页不足 page_size 时越界。解决rowCount 必须严格等于数据源的真实总行数分页加载时对最后一页做长度校验取行前先判断 offset 是否小于该页实际长度。可以在 _load_page 里记录每页真实行数fetch_row 时越界返回空字符串而不是抛异常。4.2 现象界面滚动时 CPU 飙高、滑动发涩原因data 里做了重活比如每次都对整行做格式化、字符串拼接、正则匹配或者缓存没命中导致频繁回源。解决把格式化结果缓存起来别在 data 里重复计算。检查缓存命中率如果命中率低说明 cache_size 太小或淘汰策略不对。另外确认没有在 data 里调用耗时 IO。4.3 现象修改数据后视图不刷新原因直接改了底层数据却没发 dataChanged 信号视图不知道要重绘。解决任何影响显示的数据变更都要在改完后发出 dataChanged参数是变更区域的左上和右下 QModelIndex。如果整列变了就发整列的范围。别偷懒发全表范围那会让视图重绘所有可见行白白浪费性能。4.4 现象程序内存持续增长跑久了 OOM原因缓存没有上限或者异步加载的回调持有大量临时对象不释放或者每页数据加载后没被淘汰。解决给所有缓存设硬上限行缓存、页缓存都要有淘汰。异步回调里避免闭包捕获大对象用完及时置空。可以用 QCache 替代手写 LRU它自带成本上限。4.5 现象排序或筛选后行号全乱原因自定义模型直接暴露了原始行号排序代理或筛选代理改变了视图行号到源行号的映射但 data 里还在用视图行号取数。解决如果要用 QSortFilterProxyModeldata 里拿到的 index 已经是代理的索引必须用 mapToSource 转回源模型索引再取数。或者干脆在模型内部实现排序自己维护行号映射避免代理层带来的额外开销。5. 进阶技巧用 canFetchMore 和 fetchMore 做真正的增量加载前面讲的缓存和分页本质是按需取数但 rowCount 一开始就返回了一千万视图会认为所有行都存在。如果你的数据源是逐步可用的比如从文件流式读取、从接口分批拉取更地道的做法是用 canFetchMore 和 fetchMore 实现增量加载初始只报告已加载的行数视图滚到底部时自动触发 fetchMore 追加更多行。class IncrementalModel(QAbstractTableModel): def __init__(self, headers, parentNone): super().__init__(parent) self._headers headers self._rows [] # 已加载的行 self._has_more True def rowCount(self, parentQModelIndex()): return 0 if parent.isValid() else len(self._rows) def canFetchMore(self, parentQModelIndex()): return self._has_more def fetchMore(self, parentQModelIndex()): # 每次追加一批比如 500 行 batch self._load_next_batch(500) if not batch: self._has_more False return start len(self._rows) self.beginInsertRows(QModelIndex(), start, start len(batch) - 1) self._rows.extend(batch) self.endInsertRows()逻辑说明canFetchMore 告诉视图还有更多视图在需要时会调用 fetchMore。fetchMore 里必须用 beginInsertRows 和 endInsertRows 包裹数据变更否则视图内部索引会错乱。每次追加一批而不是一行减少信号开销。参数说明批次大小 500 到 2000 比较合适太小信号频繁太大单次卡顿。_has_more 在数据取完后置 False视图就不再追问。这个模式特别适合一千万行但用户只会看前面一部分的场景初始只加载几千行界面秒开用户真滚到后面再继续加载。配合前面的行缓存可以把内存压到很低。我自己的习惯是只要数据源支持游标或偏移读取就优先用增量加载而不是一次性报告总行数这样启动体验最好。唯一要注意的是如果业务需要显示精确的总行数比如共 1000 万条得单独查一次 count别指望 rowCount 一开始就给你。希望帮到你。本文还有配套的精品资源点击获取