从数据到像素：深入 Qt Model/View 架构

在 Qt 里写界面，新手最常见的做法是"一个数据项 = 一个 QWidget"，加到布局里完事。这在几十条数据时没问题，一旦数据上千，界面立刻卡成幻灯片——因为每个 QWidget 都是重量级对象（有原生窗口句柄、样式系统、事件过滤器等开销）。Model/View 就是 Qt 给出的正解：把"数据长什么样"与"界面怎么画"彻底分离，视图只绘制可见区域，用 painter 直接渲染，从而支撑百万级数据依然流畅。

对你来说，它还有一层特殊意义：Model/View 的"模型发出变更信号 → 视图按需取数重绘"机制，和你熟悉的 Vue 响应式、React 单向数据流在思想上一脉相承，但实现层面更接近底层。学懂它，你既能快速上手任何 Qt 桌面项目（文件管理器、聊天软件、IDE 侧边栏全部建立在这套架构上），也能反向加深对前端框架设计取舍的理解。

一、三个角色，各司其职。Model（模型）持有数据，暴露统一读写接口，是唯一知道"数据怎么存"的人；View（视图，QListView / QTableView / QTreeView）只负责"怎么呈现"，它不碰数据本身；Delegate（委托，QStyledItemDelegate）负责"怎么画细节 + 怎么编辑"，是渲染与编辑的扩展点。三者通过一个极轻量的 QModelIndex（行号 + 列号 + 父索引指针）寻址数据单元。

二、索引是"用后即弃"的。QModelIndex 内部只存 row、column 和一个指向内部节点的指针，任何结构性变化（增删行）都可能导致它失效。所以官方契约是：不要在函数外长期保存 QModelIndex；需要跨异步操作持有时，用 QPersistentModelIndex，它会随结构变化自动更新。这很像 React 的 key——索引不是稳定的身份标识，只是"当前位置的快照"。

三、Roles 协议：一次 data() 调用回答所有问题。视图渲染一行数据，会带着不同 role 反复调用 data(index, role)：Qt::DisplayRole 要显示文本，Qt::DecorationRole 要图标，Qt::ToolTipRole 要提示，Qt::EditRole 要可编辑的原始值（编辑时用），Qt::UserRole + n 留给你自定义。这本质上是一个"按需求值"的查询接口：视图需要什么，才问什么。

四、信号契约：增量通知，绝不整表重来。这是 Model/View 性能的灵魂。修改数据必须发 dataChanged(topLeft, bottomRight, roles) 声明"哪些格子变了"；插入/删除行必须先用 beginInsertRows() 通知视图"我要插了"，改完数据再 endInsertRows()。视图据此只重绘受影响区域，并自动维护滚动条位置。破坏契约（比如改完数据不发信号）的后果是界面不刷新或直接越界崩溃。兜底手段是 beginResetModel()/endResetModel()，但那是"全量重建"，数据量大时应避免。

五、Proxy 与 Delegate：两道扩展闸门。QSortFilterProxyModel 套在源模型外面做排序/过滤，不改源数据、可链式组合，视图拿到的索引可用 mapToSource()/mapFromSource() 双向换算；Delegate 则接管"画"与"编辑"，自定义外观（进度条、复选框、富文本）时优先重写 paint() 与 createEditor()。

六、性能原理：按需取数 + 虚拟渲染。QListView 等视图只对可见矩形内的行调用 data()，滚动时旧行销毁、新行按需创建——这正是前端"虚拟滚动"的鼻祖。配合只发增量信号，百万行表格也能保持 60fps 滚动。

案例一：Qt 官方 QFileSystemModel 与文件管理器。深色模式下打开任何基于 Qt 的文件管理器（如 Deepin 文件管理器、KDE Dolphin），左侧目录树、右侧文件列表就是 QTreeView/QListView + QFileSystemModel 的标准组合。QFileSystemModel 内部做了目录懒加载：展开节点时才异步枚举子目录，data() 里按需读取文件大小、图标、权限——所以你进入一个含十万文件的目录也不会卡死。

案例二：微信 / QQ 桌面版的消息列表。聊天记录动辄数十万条，绝不可能每个会话/每条消息建一个 widget。消息列表本质是一个虚拟化视图 + 自定义 delegate：气泡、头像、时间戳全部由 delegate 的 paint() 直接绘制；搜索聊天记录则是 QSortFilterProxyModel 过滤 + 高亮 delegate 的典型场景。这正是 Model/View 的现实价值——同样的数据量，用"每项一个 widget"的写法早就 OOM 了。

案例三：Qt Creator 与 JetBrains 系 IDE 的侧边栏。项目文件树、编译问题列表、断点面板，都是"树/表视图 + 模型"结构；问题面板实时追加条目，靠的正是 rowsInserted 增量通知让视图只插入一行而不是整体重绘。JetBrains 虽然基于 Swing，但其 TableModel/TreeModel 抽象与 Qt 如出一辙——说明这套"模型-视图-委托"架构是所有严肃桌面框架的共同答案。

案例四：Chrome DevTools 的 Network 面板。Chromium 不是 Qt，但 Network 面板对上千条请求的表格渲染同样采用"仅渲染可视行 + 按需加载"策略。设计原因殊途同归：渲染成本与数据量解耦，界面流畅度只取决于可见区域大小，而非数据总量。理解这一点，你就抓住了 Model/View 的全部设计动机。

错误 1：改数据不通知视图。直接往内部容器里 push_back，忘了 beginInsertRows/endInsertRows 或 dataChanged。结果：界面不刷新，或者视图按过期索引取数直接越界崩溃。避免：把"改模型"封装成模型自己的方法，方法内部强制成对调用 begin/end，从结构上杜绝裸改。

错误 2：在 data() 里做重活。data() 会被视图高频调用（滚动时每个可见行、每个 role 都调一次），有人在里面读文件、查数据库、做字符串解析，滚动立刻卡顿。避免：data() 只做内存读取；昂贵计算放后台线程，结果缓存到内存，再发 dataChanged 通知刷新。

错误 3：长期持有 QModelIndex。把 index 存进成员变量或 lambda 捕获，等结构变化后再用——这是未定义行为，可能读到错误数据甚至崩溃。避免：跨异步操作改用 QPersistentModelIndex，或用"行号 + 稳定 id"自行定位。

错误 4：DisplayRole / EditRole 混用或漏实现。只实现 DisplayRole 导致双击无法编辑；或者把格式化后的字符串放 EditRole，导致编辑时拿到的是"已格式化文本"而非原始值。避免：DisplayRole 给展示形态，EditRole 给原始数据，二者职责分开，这是官方明确约定的分工。

错误 5：跨线程直接改模型。在工作线程里直接调用 model 的修改方法，与 UI 线程的渲染产生数据竞争，偶发崩溃极难排查。避免：模型必须活在拥有它的线程（通常是主线程），工作线程通过信号槽（QueuedConnection）或 QMetaObject::invokeMethod 把"修改请求"投递回去。

1. 首选 QAbstractListModel / QAbstractTableModel，而不是 QAbstractItemModel。90% 的场景是列表或表格，这两个子类把树相关的复杂度全部挡掉，只需实现 rowCount 和 data 两个方法。何时用树模型：数据结构天然分层（目录树、组织架构、JSON 树），且需要展开/折叠交互时。Trade-off：树模型索引寻址复杂，能用"扁平表 + 缩进列"表达的就别上树。

2. 排序/过滤一律走 QSortFilterProxyModel，不碰源数据。好处：可撤销、可组合（链式）、多个视图共享同一源模型时互不干扰；过滤条件变化只重建 proxy，源模型索引保持稳定。何时不用：过滤逻辑极其简单（如永远不变的空列表），或对性能极致敏感且数据量超千万——proxy 多一层索引映射有轻微开销，此时可考虑在源模型内直接维护过滤视图。

3. 大数据量用"懒加载 + 缓存 + 后台填充"三件套。data() 保持 O(1) 内存读取；昂贵数据（网络、磁盘、数据库）在工作线程预取后经信号投递回模型线程，再发 dataChanged 精准刷新。何时不用：数据量在千级以内且全在内存，直接同步填充即可，别为过度设计付出复杂度。

4. 自定义外观优先 QStyledItemDelegate，而不是在 data() 里拼富文本。delegate 的 paint() 用 QPainter 直接绘制，成本低、可控性强；data() 返回 HTML 依赖视图内置解析，性能差且样式受限。何时用简单方案：纯文本 + 图标，直接用 DecorationRole + DisplayRole 就够，delegate 是"按需重写"，别一上来就全量自绘。

5. 把"改模型"收敛为模型自身的方法，强制信号契约。addTask/removeTask 这类方法内部成对调用 begin/end，业务层永远无法绕过通知——这是用 API 设计消灭一类 bug 的典型手法。Trade-off：模型方法增多，需要克制"为每个字段写 setter"的冲动，用批量 setter + 一次 dataChanged 代替。

Model/View 和前端框架共享同一套心智模型，逐条对照，迁移成本极低：

最有价值的一个认知差：Vue 替你做了"自动追踪哪些数据被谁用了"，而 Qt 把这份责任交给了你。Vue 的响应式依赖收集 ≈ 隐式的 dataChanged 广播；Qt 则要求你精确声明"哪几行、哪几列、哪些 role 变了"。前者开发爽但运行时开销大（依赖追踪 + 批量调度），后者需要自律但零框架开销、性能可预测。理解了这层 trade-off，你就能解释为什么 Vue 的深响应式在巨型表格上需要手动 shallowRef 优化，而 Qt 从一开始就把"按需 + 增量"刻进了架构。

另一个迁移点：Qt 的 model 通常只有一个（数据源），多个视图可共享——这对应 Redux 的"单一数据源 + 多订阅者"；而 delegate 的编辑回写（setModelData）对应 Vue 的"props down, events up"：子组件不能改 props，delegate 也不能直接改 model，必须通过模型自己的接口。单向数据流的纪律在两个生态里是同一句话。

Code Review 四查：一查 begin/end 是否成对出现、范围是否正确；二查 dataChanged 是否带了精确的 roles 和范围（看到整表 modelReset 要追问原因）；三查 data() 里有没有 I/O、网络、字符串拼接这类重活；四查模型是否被跨线程触碰。

指导方法：让成员在写任何列表/表格前先画一张"数据流图"——谁拥有数据、谁发信号、谁消费信号、编辑如何回写。这张图能提前暴露 80% 的架构问题，比事后 debug 高效得多。对从 Web 转来的同学，直接套用他们熟悉的术语："你的 model 就是 store，dataChanged 就是 dispatch 后的订阅通知，delegate 就是 scoped slot"。

性能验收标准：要求任何列表功能附带"10 万条数据滚动不卡"的验收项，用 Qt 自带的性能剖析器（Qt Creator 的 Profiler）确认 data() 耗时在微秒级。把"能用"和"架构正确"分开验收，避免团队用 modelReset 糊弄出能跑但一放大就崩的实现。

任务拆解建议：新手先做"只读列表"（掌握 data 契约），再做"可编辑 + delegate"（掌握编辑回写），最后做"proxy + 异步加载"（掌握性能三板斧），三级递进，每级都有可交付的 demo。

• Qt 官方文档《Model/View Programming》——最权威、免费，含三件套概念图与完整示例代码，是任何 Model/View 问题的第一站。
• 《C++ GUI Programming with Qt 4》（Blanchette & Summerfield）第 10-11 章——把 Model/View 讲得最透彻的经典教材，虽然基于 Qt4，核心契约至今未变，适合通读建立体系。
• Qt 官方 examples/widgets/itemviews 源码——重点读 Chip Example（自定义 delegate 自绘）与 Editable Tree Model（树模型 + 编辑回写），"读例程"比"读文档"更接近真实写法。
• 《Qt 6 C++ GUI Programming Cookbook》——按问题组织的实践配方，含 proxy、拖拽、自定义模型等常见场景的即用方案。
• Qt 源码 src/corelib/itemmodels/qabstractitemmodel.cpp——想真正吃透信号契约，直接看 beginInsertRows/endInsertRows 内部如何维护 persistent 索引与通知视图，源码比任何二手解释都精确。