最开始做一个工业上位机项目时，我直接用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 线程更新 Model，emit dataChanged 就行，View 会自动刷新。线程安全和逻辑清晰瞬间解决。
classDeviceModel:publicQAbstractTableModel{Q_OBJECTpublic:introwCount(constQModelIndex&)constoverride{returndevices.size();}intcolumnCount(constQModelIndex&)constoverride{return5;}QVariantdata(constQModelIndex&index,introle)constoverride{if(role==Qt::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 撸业务泥潭了。
