最开始做一个工业上位机项目时我直接用QTableWidget展示设备状态表格想着“先跑起来再说”。表格不大功能不多写着写着还能接受。结果业务一复杂需求加了行内编辑、排序、动态刷新、状态色标识……原本简单的 QTableWidget 代码迅速变成了一坨嵌套 if、临时缓存和重复刷新的泥潭。为什么 demo 没问题项目里就开始炸QTableWidget 在 demo 里真的很方便你创建几行几列直接 setItem 就行。问题是它把 UI 和数据紧密绑定一旦业务逻辑复杂数据状态管理和 UI 更新就绑在一起。我曾经试过在 updateStatus() 里直接改 QTableWidgetItem结果刷新多了CPU 飙升甚至出现死锁。Qt 的Model/View机制解决的正是这个问题。它把数据和界面解耦Model 负责数据View 负责显示Delegate 处理渲染和编辑。真正用起来你的业务逻辑写在 Model 里View 只关心显示和交互刷新逻辑不再散落在各个槽里。真正麻烦的不是写 Model而是习惯很多人嫌麻烦不学 Model/View理由是“写个 QTableWidget 不就行了”。我也这样想过直到项目里需要多线程刷新表格设备状态从不同线程发信号过来。QTableWidgetItem 不是线程安全的连最简单的更新也要用QMetaObject::invokeMethod代码复杂得让人想哭。如果用QAbstractTableModel我只要在 worker 线程更新 Modelemit dataChanged 就行View 会自动刷新。线程安全和逻辑清晰瞬间解决。classDeviceModel:publicQAbstractTableModel{Q_OBJECTpublic:introwCount(constQModelIndex)constoverride{returndevices.size();}intcolumnCount(constQModelIndex)constoverride{return5;}QVariantdata(constQModelIndexindex,introle)constoverride{if(roleQt::DisplayRole)returndevices[index.row()].status[index.column()];return{};}};这段看着简单但在多线程采集项目里它帮我把表格刷新逻辑从槽里剥离出来业务数据更新不会直接操作 UI也不会引起奇怪的崩溃或卡死。这个细节不处理后面很容易背锅我见过的一个坑开发同事直接在 QTableWidget 里做复杂业务判断结果 bug 一旦出现没人能快速定位数据错在哪行哪列。Model/View 把数据集中管理错误能快速定位UI 不会扯乱。常见坑或经验提醒不做 Model业务越复杂越乱QTableWidget 一开始快但可维护性差。Delegate 不用好行内编辑和状态色标必须写 Delegate否则表格逻辑会散落在槽里。线程更新直接操作 QTableWidget绝对会踩坑Model 是线程安全刷新的唯一救命稻草。对象生命周期管理Model/View 里对象关系清晰QTableWidget 堆砌临时对象容易内存泄漏。最后说两句Qt Model/View 并不是高级玩家专属它是复杂表格项目的保命方案。嫌麻烦不学QTableWidget 项目里你早晚会哭。我踩过坑才理解真正的生产力不是写得快而是写得干净、易维护、出错少。如果你的表格业务逻辑一旦复杂到“行数、列数、状态、编辑、刷新、线程交错”Model/View 就该上场了。别再用 QTableWidget 撸业务泥潭了。