Qt表格卡顿优化：从QTableWidget到QTableView+Model的实战改造

开发 Qt 桌面应用做过表格的同学，十有八九都是从 QTableWidget 上手的那一批。它确实省事：行列建好，new 个 QTableWidgetItem 往里一塞，一个可编辑、可选中的表格就出来了。但如果你拿它处理几千行、上万行的数据，马上会体验到什么叫做“肉眼可见的卡顿”——加载慢、滚动掉帧、内存哗哗涨。最近我帮一个工具类项目做性能整改，就是把一套 QTableWidget 的表格重构成 QTableView + QAbstractTableModel 的方案，整个过程踩了不少坑，也把“数据量大加载慢”这类问题梳理出了一套完整的排查和优化路径。这篇文章就把我实际用下来的经验写出来，内容包括 QTableWidget 的定位、基本用法、性能瓶颈分析、从应急优化到架构级改造的完整步骤，还有高频问题的排查清单。不管你是刚入门 Qt 的新手，还是被大数据量表格折磨过的老开发，都能从这里找到能直接抄作业的方案。

1. QTableWidget 到底是什么——先搞清楚它的定位

很多人在遇到性能问题之前，根本没仔细想过 QTableWidget 和 QTableView 的区别。两者在界面上看起来几乎一样，但内部机制完全不同。搞清楚定位，后续所有方案才好选。

1.1 和 QTableView 的区别与选择逻辑

QTableWidget 是 QTableView 的子类，官方称之为“方便类”。它走的是一种 Item-Based（条目驱动）的模式：你负责为每一个单元格创建 QTableWidgetItem 对象，然后交给表格持有。表格内部维护着一个“二维条目池”，界面展示和数据处理都绑定在这些 item 上。

QTableView 则是标准的 Model/View 架构：视图只管“画”，数据由 QAbstractTableModel 的子类按需提供。视图自己手里不存具体内容，每次需要画某个单元格时，就向模型发请求拿数据。

用生活化的类比来说：QTableWidget 像你把所有东西都搬进 Excel 表格里，表格本身既管存储又管展示；QTableView 像只放了一个报表查询界面，你需要什么数据，它现场去数据库里帮你查。

这个差异决定了选型逻辑：

选择依据很简单：如果你只是做一个小工具内的配置表、结果列表，总量稳定在一两千行以内，QTableWidget 完全没问题，没必要上模型架构自找麻烦。但只要你敢说“数据量可能很大”“数据来自数据库或接口”“后面要做复杂排序筛选”，那我劝你从第一天就用 QTableView。

1.2 适合 QTableWidget 的典型场景

我自己项目中仍然保留 QTableWidget 的场景主要有三类：

第一类是设置面板和参数表格。比如协议配置、告警阈值表、键值映射表，行数往往二三十行，手动编辑需求强，用 QTableWidget 加几个 QTableWidgetItem 的 flag 控制编辑权限，非常快捷。

第二类是临时结果展示。比如批量任务的执行结果列表、文件扫描的统计表，数据是程序运行中临时生成的，用完即弃，不需要持久化。

第三类是快速原型和演示 Demo。产品经理说“我就要一个能看能点的表格”，你用 QTableWidget 半小时交付，后面如果数据量真上来了再重构，这种取舍是合理的。

但这里有个提醒：即使在这些“轻量”场景里，一旦行数过了 1000 且列数不少，QTableWidget 的笨重感就会显现出来。我见过一个日志展示面板，每次搜索结果显示两三千条，刷新时界面直接卡死几秒，原因就是每次刷新时把整表的 item 全部销毁再重建。这类问题在后文会有对应的解法。

2. 基础用法与新手最容易踩的坑

聊优化之前，先把基本功打牢。QTableWidget 的基础用法看起来简单，但有几个细节没做好，后面就会变成性能或逻辑上的雷。

2.1 初始化表格与填充数据的基本流程

一个最基础的初始化顺序是这样的：

cpp复制QTableWidget *table = new QTableWidget(this);

// 1. 先设置列数，再设置表头
table->setColumnCount(5);
QStringList headers = {"ID", "名称", "状态", "创建时间", "备注"};
table->setHorizontalHeaderLabels(headers);

// 2. 一次性预留行数
table->setRowCount(100);

// 3. 填充数据
for (int row = 0; row < 100; ++row) {
    for (int col = 0; col < 5; ++col) {
        QTableWidgetItem *item = new QTableWidgetItem(
            QString("item%1_%2").arg(row).arg(col));
        table->setItem(row, col, item);
    }
}

有几个细节值得注意。setRowCount 最好一次性设置，别在循环里反复调用。它涉及内部存储空间的分配，频繁调用会产生不必要的内存操作和布局重算。

另外，如果某些单元格只是展示用，不需要用户编辑，记得去掉编辑标志：

cpp复制QTableWidgetItem *item = new QTableWidgetItem(value);
item->setFlags(item->flags() & ~Qt::ItemIsEditable);

还有一点，QTableWidgetItem 不是 QObject，不需要也不能指定 parent，用 new 创建后交给 setItem 即可，表格内部会负责管理它的生命周期。新手常见错误是担心内存泄漏乱 delete，结果反而造成悬空指针。你只管把 item 交给表格，不要在插入后再手动 delete。

2.2 表头、编辑、选择这几件事的配置细节

表头除了显示文本，还能控制排序、列宽和上下文菜单。实际项目里我通常会做这几项配置：

cpp复制// 允许点击表头排序，但注意插入大量数据时要先关掉
table->setSortingEnabled(false);

// 编辑触发方式：双击或按 F2 进入编辑
table->setEditTriggers(QAbstractItemView::DoubleClicked
                       | QAbstractItemView::EditKeyPressed);

// 整行选中 + 单选，这是最常见的两种方式
table->setSelectionBehavior(QAbstractItemView::SelectRows);
table->setSelectionMode(QAbstractItemView::SingleSelection);

// 最后一列拉满剩余宽度，避免右侧大片空白
table->horizontalHeader()->setStretchLastSection(true);

选择模式这块一定要按业务来。如果只是展示统计结果，用 SelectRows 加上 SingleSelection，用户点击行为会很自然；如果是做一个类 Excel 的交叉表，可能更需要 SelectItems + ExtendedSelection。配置错了，交互体验会非常别扭，比如用户想只选一个单元格，结果整行都被高亮了。

这里有一个经常被忽略的小细节：setSortingEnabled(true) 之后，插入新行的顺序可能被自动重排，导致“我明明 setItem 在第 0 行，怎么表格里跑到了第 5 行”。所以我会在批量填充数据前先关闭排序，全部插完后再开：

cpp复制table->setSortingEnabled(false);
// 批量插入...
table->setSortingEnabled(true);

2.3 外观调优：QSS、交替行色与列宽处理

表格美化相对简单，但 QSS 命名的选择器容易踩坑。这里给一套我常用的基础样式：

css复制QTableWidget {
    background-color: #ffffff;
    alternate-background-color: #f5f7fa;  /* 交替行色 */
    gridline-color: #e0e0e0;
    selection-background-color: #409eff;
    selection-color: #ffffff;
}

QHeaderView::section {
    background-color: #f0f2f5;
    padding: 6px;
    border: none;
    border-right: 1px solid #e0e0e0;
    font-weight: bold;
}

对应在代码里要打开交替行色开关：

cpp复制table->setAlternatingRowColors(true);

关于列宽，新手最爱在数据填充完以后直接调 resizeColumnsToContents()。这个函数在几十行时没事，但几千行时会让耗时直线上升，因为它要遍历所有行去计算内容宽度。大数据量下我的做法是：只有对前 N 行做宽度预估，其他列用固定宽度或占满剩余空间。

cpp复制// 只根据前 50 行估算列宽，避免全表扫描
table->resizeColumnsToContents();
// 大数据量下可以手动指定列宽策略，或自定义 toContents 的样本行数

我还见过直接把 QTableWidget 嵌进布局后不管行高列宽的，结果窗口拉伸时表格内容都被挤变形。正确做法是给表头设置合适的尺寸调整模式：ResizeToContents、Interactive、Fixed 按需选。

3. 数据量一大就卡？先找到瓶颈在哪

拿着 QTableWidget 处理上万行的数据，卡顿几乎是必然的。但卡顿到底卡在哪，很多人说不清楚。只有定位到具体环节，优化才有方向。

3.1 卡顿问题出在哪几个环节

我总结下来，QTableWidget 数据量大时的性能问题主要来自四个环节：

第一是 item 对象的内存开销。每个单元格都是一个 QTableWidgetItem 堆对象，里面有 QString、标志位、数据角色等内部字段。10000 行 × 10 列就是 10 万个对象。粗略估算，每个对象加内部数据至少 64 到 128 字节，光这些对象就是 8 到 13 MB，还没算 QString 各自的缓冲区、信号槽管理带来的额外开销。

第二是界面重绘。每次 setItem 都会触发视图的局部更新甚至布局重算。循环里插入大量 item 时，等于是让表格不停地重画自己，就像每写一个字就刷新一次整个 Word 文档。

第三是内部数据结构维护。QTableWidget 需要维护行列坐标到 item 的映射、排序状态、选择状态等。行数越多，这些索引维护成本越高。

第四是信号传播。item 变化会触发 itemChanged、cellChanged 等信号，如果你还连接了槽函数做联动逻辑，每次插入都可能引起一连串后续操作。

我很早就用一个很土的方法定位瓶颈：在循环前后用 QElapsedTimer 记录耗时，再做二分式注释排查。这个方法土，但真实有效。

3.2 用计时器实测，别靠感觉判断

光说“卡”不够，要用数字说话。我在排查一个日志工具时，清零之后重新加载 10000 行 × 8 列数据，测试代码大概是这样的：

cpp复制QElapsedTimer timer;
timer.start();
for (int row = 0; row < 10000; ++row) {
    for (int col = 0; col < 8; ++col) {
        QTableWidgetItem *item = new QTableWidgetItem(...);
        table->setItem(row, col, item);
    }
}
qDebug() << "insert elapsed:" << timer.elapsed() << "ms";

当时的结果是 80000 个 item 插进去，大约花了 2600 到 3200 毫秒。在普通配置的机器上已经非常明显，用户看到的就是界面卡死两三秒。

接着我把填充过程包进 setUpdatesEnabled(false) 和 setUpdatesEnabled(true) 之间，再测，耗时会明显下降，但在更大的数据量下依旧不够看。这说明重绘开销只是问题的一部分，item 对象本身的创建和管理开销才是大头。

要区分“初始化慢”还是“滚动卡”，可以这样判断：加载完成后拖动滚动条，如果明显卡顿，说明滚动过程中还有大量绘制或布局计算；如果加载慢但滚动还行，说明瓶颈更多集中在插入阶段。两种问题的针对性方案不一样，前者要靠减少 item 创建来解决，后者要靠视图渲染机制优化来解决。

3.3 为什么 Model/View 架构天生更抗造

同样一个日志工具，我后来把表格换成了 QTableView + 自定义 QAbstractTableModel，同样的 10000 行，加载耗时从 3 秒左右降到几百毫秒以内，滚动也顺滑了。差别在哪？

在 Model/View 架构里，视图不知道也不关心一共有多少 item。它只按当前可视区域的行列号去问 Model “你这第 i 行第 j 列显示什么”，Model 实时返回一个 QVariant。数据本身存在你自己的业务容器（比如 QVector<Record>）里，不从单元格对象复制过来。

这个模式有点像短视频 App 的信息流：你滑到哪一屏，它才加载哪一屏的内容。而 QTableWidget 相当于一次性把所有视频都下载到本地，不卡才怪。

所以结论很明确：数据量大加载慢的根因，不是 Qt 渲染慢，而是你把“存储数据”和“展示数据”两件事混在了一起。要根治，就得把它们分开——这正是 Model/View 架构做的事。

4. 性能优化：从应急手段到架构升级

优化 QTableWidget 性能有一条从浅到深的路线：先做不换框架的应急提速，再考虑迁移到 Model/View 架构，数据量再大就上懒加载和委托绘制。下面按这个顺序讲。

4.1 还在用 QTableWidget 场景下的应急提速

如果你项目里暂时不方便重构，或者数据量只是偶尔冲到几千行，下面这组“三板斧”可以快速缓解问题。

第一板斧是关闭界面更新，批量插入完成后一次性刷新：

cpp复制table->setUpdatesEnabled(false);
table->setSortingEnabled(false);

for (int row = 0; row < rowCount; ++row) {
    // 一次性创建本行所需 item
    for (int col = 0; col < colCount; ++col) {
        // setItem...
    }
}

table->setSortingEnabled(true);
table->setUpdatesEnabled(true);

第二板斧是屏蔽信号。如果你的代码里连接了 itemChanged 之类的信号用来做联动校验，插入期间信号会大量触发。插入前 blockSignals(true)，插入后再恢复。但要注意：如果你在插入过程中确实需要这些信号，那这招就不能用，或者改成用标志位做阈值合并。

第三板斧是复用 item 对象。有些实时刷新场景，比如日志表格每秒更新若干行，与其删除旧 item 再 new 新的，不如直接调用 item(row, col)->setText(newText) 更新。这样可以避免大量对象创建和销毁的开销。

我再补充一个更“绕”但有效的做法：把 10 列拆成 5 列加 5 列？其实不是。真正有效的思路是减少列数。展示类业务里很多列是为了“信息完整”而不是“用户必看”，可以做成默认隐藏列，需要时再展开。列数是 item 数量的直接乘数，砍掉一半列，内存和插入耗时直接减半。

4.2 一劳永逸的迁移：QTableView + QAbstractTableModel

应急手段治标不治本。如果数据量一定会持续增长，我最推荐的做法就是抽时间重构到 QTableView + QAbstractTableModel。这个迁移有个额外好处：数据逻辑被收拢到 Model 层，业务代码反而更好维护。

先看一个最简的自定义 Model 长什么样。假设业务数据是这么个结构：

cpp复制struct Record {
    int id;
    QString name;
    QString status;
    QString createTime;
    QString remark;
};

Model 的核心代码：

cpp复制class TableModel : public QAbstractTableModel
{
    Q_OBJECT
public:
    explicit TableModel(QObject *parent = nullptr)
        : QAbstractTableModel(parent) {}

    void setRecords(const QVector<Record> &records) {
        beginResetModel();
        m_records = records;
        endResetModel();
    }

    int rowCount(const QModelIndex &parent = QModelIndex()) const override {
        Q_UNUSED(parent);
        return m_records.size();
    }

    int columnCount(const QModelIndex &parent = QModelIndex()) const override {
        Q_UNUSED(parent);
        return 5;
    }

    QVariant data(const QModelIndex &index, int role = Qt::DisplayRole) const override {
        if (!index.isValid() || index.row() >= m_records.size())
            return QVariant();

        const Record &rec = m_records.at(index.row());
        if (role == Qt::DisplayRole) {
            switch (index.column()) {
            case 0: return rec.id;
            case 1: return rec.name;
            case 2: return rec.status;
            case 3: return rec.createTime;
            case 4: return rec.remark;
            }
        } else if (role == Qt::TextAlignmentRole) {
            if (index.column() == 0 || index.column() == 3)
                return int(Qt::AlignCenter);
        }
        return QVariant();
    }

    QVariant headerData(int section, Qt::Orientation orientation,
                        int role = Qt::DisplayRole) const override {
        if (role != Qt::DisplayRole)
            return QVariant();
        if (orientation == Qt::Horizontal) {
            const QStringList headers = {"ID", "名称", "状态", "创建时间", "备注"};
            return headers.value(section);
        }
        return section + 1;
    }

private:
    QVector<Record> m_records;
};

使用的方式很简单：

cpp复制TableModel *model = new TableModel(this);
model->setRecords(allRecords);

ui->tableView->setModel(model);
ui->tableView->horizontalHeader()->setStretchLastSection(true);

关键点在于 data() 里面不要做耗时操作，也不要每次 new 对象。它返回的是 QVariant，由值传递交给视图，是轻量级的。真正权重最高的是你的业务容器 m_records，它决定了内存占用。因为视图只会请求可见区域的数据，所以 10000 行的表加载起来才会那么快。

重构时有个常见误区：有人写 Model 时，还在 data() 里把业务数据复制进 QTableWidgetItem 再返回，等于绕了一圈还是 item 那套，优化了个寂寞。记住，data() 里直接返回 QVariant 就行。

4.3 懒加载与增量加载：数据量无限大时的解法

如果你面对的是几十万行甚至上百万行的数据，就算是 QTableView，一次性把所有业务数据加载进内存也不是最优解。这时可以用 canFetchMore() 和 fetchMore() 做懒加载，这是 QAbstractItemModel 原生支持的增量加载机制。

思路是这样的：Model 内部维护一个“已加载数据量”，初始只加载前 N 条，视图滚动到底部附近时，框架会调用 canFetchMore() 询问还有没有更多，返回 true 就继续调 fetchMore() 追加数据。

cpp复制bool TableModel::canFetchMore(const QModelIndex &parent) const override {
    Q_UNUSED(parent);
    return m_loadedCount < m_totalCount;
}

void TableModel::fetchMore(const QModelIndex &parent) override {
    Q_UNUSED(parent);
    int remainder = m_totalCount - m_loadedCount;
    int itemsToFetch = qMin(500, remainder);

    beginInsertRows(QModelIndex(), m_loadedCount, m_loadedCount + itemsToFetch - 1);
    // 从数据源（数据库游标/接口分页）读取 itemsToFetch 条，追加进 m_records
    appendFromSource(m_loadedCount, itemsToFetch);
    m_loadedCount += itemsToFetch;
    endInsertRows();
}

beginInsertRows 和 endInsertRows 这两个必须成对调用，它们会通知视图在指定位置插入新行。漏掉任何一个，视图和模型的数据一致性就崩了。

另一种更可控的做法是自己实现滚动条触底加载：连接 verticalScrollBar()->valueChanged，当值大于等于最大值减一个阈值时，主动调用 Model 的加载方法。这样做的好处是可以自己控制预加载的“提前量”，让用户感知不到分页过程，体验更平滑。

懒加载这一节我要特别提醒：如果 canFetchMore 返回 true 但数据源迟迟拿不到数据，视图会保持“可继续下拉”的状态，但界面不会卡死，这一点实测比在 UI 线程里同步加载全部数据好太多。

4.4 用 QStyledItemDelegate 替代 setCellWidget

很多新人做表格里的状态显示、按钮、进度条时，第一反应是 setCellWidget()。确实，往某个单元格塞一个 QWidget 很容易。但你要明白：setCellWidget 的本质是在表格内创建真正的子窗口控件，100 行无所谓，1000 行就是 1000 个控件实例，性能直接崩盘。内存开销大，事件处理线程也会变得很沉重。

正确的做法是用 QStyledItemDelegate 的 paint() 去绘制内容。它不创建控件，只是希望在某个单元格里画什么、画成什么样，Qt 的绘制系统会高效渲染。

举个例子，我要在“状态”列画一个“绿色圆点 + 正常”的样式：

cpp复制class StatusDelegate : public QStyledItemDelegate
{
public:
    void paint(QPainter *painter, const QStyleOptionViewItem &option,
               const QModelIndex &index) const override {
        if (index.column() != 2) {
            QStyledItemDelegate::paint(painter, option, index);
            return;
        }

        painter->save();
        // 先画默认背景，保证选中高亮等行为不变
        QStyleOptionViewItem opt = option;
        initStyleOption(&opt, index);
        QStyle *style = opt.widget ? opt.widget->style() : QApplication::style();
        style->drawPrimitive(QStyle::PE_PanelItemViewItem, &opt, painter, opt.widget);

        QString status = index.data().toString();
        QColor color = (status == "正常") ? QColor(0x22, 0xc5, 0x5e)
                                          : QColor(0xff, 0x4d, 0x4f);

        // 画圆点
        QRectF circle(opt.rect.left() + 8, opt.rect.center().y() - 4, 8, 8);
        painter->setPen(Qt::NoPen);
        painter->setBrush(color);
        painter->drawEllipse(circle);

        // 画文字
        QRect textRect = opt.rect.adjusted(24, 0, -4, 0);
        painter->drawText(textRect, Qt::AlignVCenter | Qt::AlignLeft, status);

        painter->restore();
    }
};

然后把委托设置到表格的指定列：

cpp复制ui->tableView->setItemDelegateForColumn(2, new StatusDelegate(this));

这样的绘制方式，无论数据量多大，绘制的开销都集中在你主动画的那几个图形上。而如果你用 setCellWidget，每滚动一行，Qt 都需要创建、移动、销毁控件，滚动流畅度会变成灾难。

同样的思路也适用于编辑。如果你需要某一列用下拉框编辑，继承 QStyledItemDelegate，在 createEditor() 里返回 QComboBox 即可。这个编辑器只在真正进入编辑状态时才创建，平时不占用资源。

4.5 排序与筛选的正确打开方式

最后聊排序和筛选。前面提到过 setSortingEnabled(true) 配合大量插入是个坑。那数据量大了以后应该怎么处理？我建议把排序和筛选的职责交给代理模型 QSortFilterProxyModel。

结构上这样组织：原始数据 Model 只管原始顺序，外层套一个 QSortFilterProxyModel 负责排序和过滤，视图只认代理模型：

cpp复制QSortFilterProxyModel *proxy = new QSortFilterProxyModel(this);
proxy->setSourceModel(model);
proxy->setSortRole(Qt::DisplayRole);
ui->tableView->setModel(proxy);
ui->tableView->setSortingEnabled(true);

这样用户点击表头排序时，排序发生在代理层，原始 Model 的数据顺序不受影响。业务逻辑取数据永远按照 index.row() 映射回源 Model 的行号，再定位业务数据，完全不怕“排序后数据错位”的问题。

筛选也是一样。给代理设置一个过滤函数，按关键字过滤时性能相对可控：

cpp复制proxy->setFilterRole(Qt::DisplayRole);
proxy->setFilterKeyColumn(1); // 按名称列过滤
proxy->setFilterFixedString(keyword);

真实业务里如果数据来自数据库，我更推荐把过滤下推到 SQL 层，而不是把所有行都拉到内存里再给 QSortFilterProxyModel 过滤。内存里过滤适用于中等数据量，数据量再大就交给数据源。

5. 常见问题排查实录与避坑清单

这一部分整理我在实际项目里遇到的高频问题，每一条都是真实踩过坑之后的经验，按“问题 - 原因 - 解决”列出来，方便你直接对号入座。

5.1 加载一万行数据要好几秒，怎么办

原因：循环里 setItem 大量触发重绘，同时创建了海量 QTableWidgetItem 对象。

解决：先做应急优化，setUpdatesEnabled(false) + blockSignals(true) + 插入完再开排序。整体耗时通常能降到原来的三分之一左右。但要想彻底解决，就要走 4.2 节的迁移方案，换成 QTableView + Model。实测同样一万行，Model 方案能把耗时控制在一两百毫秒以内。

如果你怀疑是某些单元格内容本身导致渲染慢，比如混入了超大 HTML 富文本，可以单独放开一列测试，看看耗时是否集中。很多“卡”其实是某个单元格内容太长，导致文本布局计算开销巨大。

5.2 内存占用为什么这么高

原因：QTableWidget 为每个单元格维护一个 QTableWidgetItem 对象，数据重复存储，且对象有内部元数据开销。

解决：如果是 QTableWidget 没法避免，尽量减少列数、避免大字符串重复存储。如果上 Model，内存就回到业务数据本身的体量。举个例子，10000 行 × 10 列，90% 的单元格可能都是复读机式短文本，但每个 QString 都是独立分配的，内存自然膨胀。

排查内存用 Qt Creator 自带的工具或系统监控都行。我建议先记录加载前后的内存差值，再对照业务数据预估的体量，如果差异过大，基本可以断定是 item 对象开销。

5.3 排序后取数据错位

原因：直接开 setSortingEnabled(true) 后，表格的行顺序是视觉顺序，但业务数据里的索引可能并没有跟着变。从 item(row, col) 里取出的内容和业务对不上。

解决：别依赖显示坐标拿业务数据。一条正道是给 item 或 Model 增加一个隐藏的数据角色，把业务 ID 存进去。比如 QTableWidgetItem 里用 setData(Qt::UserRole, recordId)，后续用 data(Qt::UserRole) 拿回原始 ID。在 Model/View 下更干净：从 proxy->mapToSource() 拿到源 Model 的索引，再用源索引定位业务数据。

cpp复制QModelIndex proxyIndex = tableView->currentIndex();
QModelIndex sourceIndex = proxy ? proxy->mapToSource(proxyIndex) : proxyIndex;
Record rec = model->recordAt(sourceIndex.row());

5.4 界面刷新不及时/改了 item 不生效

原因：修改了 QTableWidgetItem 之后，界面没有收到刷新通知；或者在子线程直接改了 UI。QTableWidgetItem 更新后理论上会通知视图，但在某些批量操作或模型被代理包了一层的情况下，通知链路可能会中断。

解决：改完 item 后手动调用 table->viewport()->update() 强制重绘。如果是 Model 数据变化，必须在 Model 内发出正确的信号：

cpp复制// 更新单格数据
dataChanged(index, index);
// 更新整列/整行
dataChanged(index(0,0), index(rowCount()-1, columnCount()-1));

如果数据在子线程产生，绝对不能直接操作 QTableWidget 或修改 Model 内部容器，要借助信号槽的队列连接，把数据传回主线程再更新。这点我在日志系统里踩过，后台线程日志高频写入，如果在后台线程直接建 item 塞表格，轻则偶发闪退，重则直接崩溃。

5.5 需要定位到某一行/保持在某个位置

排查时还有个高频诉求：表格刷新后，要自动滚动到刚才选中或最后一条记录的位置。QTableWidget 可以用 scrollToItem()，QTableView 可以用 scrollTo()：

cpp复制QModelIndex target = model->index(row, 0);
tableView->scrollTo(target, QAbstractItemView::PositionAtCenter);

注意大数据量下频繁调用 scrollTo 本身也有开销，建议只在定位动作发生时调用一次，不要在滚动事件里反复触发。

另外，刷新后若想保持原来的滚动位置，我一般记录当前 verticalScrollBar()->value() 和第一个可见行的索引，刷新完成后再恢复。这个逻辑看着简单，实际调试时会发现行高不一致会导致滚动位置偏差，稳妥做法是记录第一个可见行的行号，通过 scrollTo 定位回去。

6. 我的真心建议

做了这么多年 Qt 开发，我的体会是：QTableWidget 是“新手友好型”组件，也是“性能陷阱型”组件。它最大的问题不是功能缺失，而是太多人把它当成万能表格，等数据量上来再来补救，成本远比一开始选对架构高。

所以我的建议非常直接：如果你现在做的是一个新项目，表格数据来源是数据库、接口、日志文件这类不可控的外部数据，请直接上 QTableView + QAbstractTableModel。即便当下数据量只有几百行，多花的半天开发时间，就是在为未来的稳定性和可维护性买保险。

如果你手头已经有了跑得不算太慢的 QTableWidget 代码，也不要焦虑。先用第 4.1 节的应急手段把明显卡顿压下去，然后挑一个业务迭代的空窗期，把表格层重构成 Model 架构。重构时记得保持业务数据结构不变，只把展示层换成 Model/View，风险其实很小。

最后再分享一个我操作中的小技巧：不管是 QTableWidget 还是 QTableView，大数据量下都不要在 data()、paint() 这类高频回调里做耗时操作，比如字符串拼接、磁盘读、内存分配。把这些事全部提前到数据准备阶段处理完，界面这一层只做“取现成结果”和“画出来”两件事，性能自然就稳了。表格组件的优化核心其实就是一句话：展示和存储分离，视图只服务可见区域，数据再大也扛得住。