在 Qt 的日常开发里，很多人一开始接触的都是 QListWidget、QTableWidget 这些现成控件，拖进来就能用，数据往里面一塞就完事。可只要数据量一上来，或者数据结构稍微复杂一点——比如要展示一棵目录树、要在同一个视图里混合不同类型的数据、要用内存里的自定义对象而不是数据库表——这些控件就开始使不上劲了。这时候就得自己动手实现 QAbstractItemModel，这也是很多 Qt 开发者从"会用控件"到"理解框架"的一道分水岭。这篇文章就围绕 QAbstractItemModel 的自定义实现，把模型/视图（MVC）这套架构从原理到落地整个梳理一遍，适合已经能熟练使用 Qt 基础控件、但还没有深入接触过模型/视图层级的开发者，也适合被 QStandardItemModel 的性能和灵活性卡住、想自己掌控数据展示逻辑的朋友。
1. 为什么要自定义模型：从现成控件到模型 / 视图架构
1.1 什么时候应该放弃现成控件
先说一个我自己的判断标准：当你发现自己在用 QTableWidget 做了大量"把数据从结构体往 cell 里搬"的重复劳动，而且每次数据一变都要手动刷新单元格、手动维护行数、手动处理排序和增删的时候，就该考虑模型/视图方案了。
QTableWidget 这类"Item-based"控件的本质是把数据和显示逻辑绑死在一起，每个单元格就是一个 QTableWidgetItem 对象。数据量小的时候没什么感觉，一旦数据到几千行，或者你需要从多个数据源聚合数据，这种绑死的做法就会带来双重浪费：内存里既要存原始数据，又要存一份 UI 层的 item，两边还得时刻保持同步。而 QAbstractItemModel 实现的"View-based"方案里，视图只负责显示，它不去持有数据，只是按需向模型提问"第几行第几列显示什么"，数据本身在你自己定义的结构里只存一份，彻底消灭了同步问题。
1.2 模型 / 视图 / 代理三者怎么分工
Qt 的模型/视图架构说起来是 MVC，但实际拆得更细，每个角色管的事很清楚：
- 模型（Model）管数据，负责告诉视图"有多少行多少列、某个位置的数据是什么"。
- 视图（View）管显示，QTableView、QTreeView、QListView 这些只负责把模型答应的内容画出来，并处理用户的点击、滚动、选择这些交互。
- 代理（Delegate）管编辑和绘制细节，可以理解为"视图里每个单元格的定制画师"，模型给原始数据，代理决定怎么画、编辑框长什么样。
- 选择模型（SelectionModel）管选中状态，一个模型可以被多个视图共享，选中信息可以作为独立的状态在视图之间同步。
这个分工带来的最大好处是，同一个数据模型挂到表格视图是表，挂到树视图就是树，视图根本不需要知道数据长什么样。我实际做过一个项目，同一份目录结构数据，一个窗口用 QTreeView 展示层级，另一个窗口用 QTableView 平铺显示筛选后的结果，两个视图共享一个自定义模型，选中的节点还能通过共享的 QItemSelectionModel 联动，这套东西用 Item-based 控件做起来会非常痛苦。
1.3 选型：QStandardItemModel 与自定义模型的边界
很多人会有个疑问：QStandardItemModel 也是模型，用起来还方便，为什么非要自己实现？
我的经验是，QStandardItemModel 适合原型验证、数据量不大、结构比较规整的场景，它内部帮你管理了大量 item 的生命周期。但它有一个绕不过去的坑：每插入一条数据就要创建一个 QStandardItem 对象，这个对象既包含数据又包含视图状态，本质上还是"一条数据一份 UI 对象"的老路子，只是外包了一层模型接口。当你的数据本身已经是结构化的（比如一个 struct 数组、一棵对象树），QStandardItemModel 反而成了障碍——你得先把数据翻译成 item，再塞进模型，数据一变又要同步 item，翻译层写起来又臭又长。
自定义 QAbstractItemModel 真正的主场是这几种情况：数据本来就有清晰的层次结构或复杂关系、原始数据量很大且集中在内存/数据库/网络、同一个数据需要被多个视图以不同形式展示、以及希望在模型中封装业务逻辑（比如权限过滤、实时计算字段）。选了自定义路线，模型就成了你的业务数据和 UI 层之间的唯一桥梁，你只需要实现几个纯虚函数，剩下的事情框架帮你安排好。
2. QAbstractItemModel 核心接口逐一拆解
2.1 QModelIndex 到底是什么
在深入接口之前，必须先把这个东西搞明白，因为后面所有函数都在跟它打交道。QModelIndex 本质上是一个轻量的"地址"，它由三部分组成：行号 row、列号 column、以及一个指向内部节点的 void 指针。前两个好理解，最后的指针是留给模型自己用的——你在创建 index 的时候，可以通过 createIndex 把任意指针塞进去，Qt 不关心这个指针是什么，它只负责在视图和模型之间传递这个地址。
这就像你去大型商场找人，只看门牌号（row/column）可能不够，不同楼层都有相同的门牌号，还得看楼层编号（内部指针）。QModelIndex 还有一个 isValid() 方法，用于判断这个地址是否还指向有效节点。注意，QModelIndex 是"瞬时"的，同一位置的 index 每次调用 index() 函数都会生成一个新的对象，你绝对不能长时间保存一份 index 等到下次事件循环再用——后面我会专门讲这个坑。
要特别区分 QModelIndex 和 int 类型的行号：行号是"相对父节点"的编号，一个在 QTreeView 里展开的树，某个节点的行号是相对于它父节点而言的，脱离了父节点单独说"第 3 行"没有意义。所以所有接口都要求带着 parent 参数一起传。
2.2 只读接口组：index、parent、rowCount、columnCount、data
这一组接口是模型的地基，任何一个自定义模型都躲不开。它们的职责分别是：
- rowCount(parent) 和 columnCount(parent)：告诉视图某个父节点下有多少行、多少列。
- index(row, column, parent)：根据行、列和父节点，生成一个合法的 QModelIndex。
- parent(child)：返回某个节点的父节点的 QModelIndex，顶层节点和无父节点的节点返回 QModelIndex()。
- data(index, role)：返回某个位置的数据，role 区分用途，比如 Qt::DisplayRole 是显示文本，Qt::EditRole 是编辑框用的值，Qt::ToolTipRole 是悬浮提示。
实现这些函数的核心是"模型的内部数据结构和 QModelIndex 之间的映射"。举个例子，如果你的数据是一棵节点树，每个节点有自己的 children 列表，那 index() 的逻辑就是：通过 parent 拿到父节点，再从父节点的 children 里取出第 row 个，用 createIndex(row, column, 这个子节点的指针) 返回。parent() 的逻辑反过来：拿到 index 对应的节点，返回它父节点的 index。这套映射只要设计好了，剩下的就是机械劳动。
关于 data() 我有个经验：先根据 index 解析出内部数据对象，再根据 role 决定返回值。很多人喜欢把业务数据直接塞进 DisplayRole，但这样做会导致编辑和显示无法区分——我建议 DisplayRole 永远返回用户最终看到的文本，EditRole 返回可编辑的原始值，其他 role 按需实现。这样后续接代理、接搜索过滤都会方便很多。
2.3 头与标志：headerData、flags
headerData(section, orientation, role) 负责生成表头。列头一般返回字段名，行头在表格里通常返回行号，在树里可以返回节点名。这里有一个不起眼但很重要的细节：表头也是按 model index 走的——section 是相对于父节点的 section 编号，在层级结构里，不同层级可以有各自不同的列头。
flags(index) 决定某个位置可不可以选中、可不可以编辑、可不可以拖拽。它返回一个 Qt::ItemFlags 的位组合。常见的组合是：
Qt::ItemFlags MyModel::flags(const QModelIndex &index) const { if (!index.isValid()) return Qt::NoItemFlags; return Qt::ItemIsEnabled | Qt::ItemIsSelectable | (index.column() == 1 ? Qt::ItemIsEditable : Qt::NoItemFlags); }我第一次写自定义模型的时候，漏了 flags，结果视图显示正常但双击无法编辑，排查了半天才发现是默认 flags 根本没开 ItemIsEditable。这个函数看似简单，但它是视图交互能力的总开关，编辑、拖拽、选中策略统统由它控制。
2.4 写接口：setData、dataChanged 与编辑流程
只读模型只是第一步，真正让模型有用的是能写、能增删。Qt 的编辑流程是这样的：用户在视图上双击，视图通过 flags 判断可编辑，然后从 data() 取 EditRole 的值放进编辑器；用户改完确认，视图调用模型的 setData(index, value, EditRole)；模型需要自己检查这个值合不合法，如果需要接受，就更新内部数据，然后发出 dataChanged 信号。
dataChanged 是整个流程的灵魂。它有两个参数：左上角 index 和右下角 index，表示变化的区域范围。发出这个信号之后，视图才知道要重新绘制哪些格子。如果模型不支持这个 role 或者不接受这次修改，setData 返回 false，视图会认为编辑被拒绝。
一个很容易踩的坑是忘记发 dataChanged，结果 setData 返回了 true、内部数据也改了，但界面纹丝不动，直到下一次别的刷新才偶然更新。我建议把"内部数据更新"和"发信号"绑在一个函数里，任何修改入口都走同一个内部方法，确保不会漏广播。
3. 实操：实现一个可用的只读树形模型
3.1 数据结构与模型设计
理论说了半天，还是上手写一个完整的模型最管用。我的例子选了一个很常见的需求：展示文件目录树，每个节点包含名称、大小、是否是目录这三个字段。为了把注意力放在模型而不是文件系统上，这里用一个简单的内存 Node 结构，省略真实的磁盘扫描逻辑。
class FileTreeModel : public QAbstractItemModel { Q_OBJECT public: explicit FileTreeModel(QObject *parent = nullptr); ~FileTreeModel(); // 只读接口 QModelIndex index(int row, int column, const QModelIndex &parent = QModelIndex()) const override; QModelIndex parent(const QModelIndex &child) const override; int rowCount(const QModelIndex &parent = QModelIndex()) const override; int columnCount(const QModelIndex &parent = QModelIndex()) const override; QVariant data(const QModelIndex &index, int role = Qt::DisplayRole) const override; QVariant headerData(int section, Qt::Orientation orientation, int role = Qt::DisplayRole) const override; Qt::ItemFlags flags(const QModelIndex &index) const override; private: struct Node { QString name; qint64 size; bool isDir = true; Node *parent = nullptr; QVector<Node*> children; }; Node *m_root = nullptr; Node *nodeForIndex(const QModelIndex &index) const; };这个示例的数据结构充分体现了"模型只是数据的翻译器"这一思想——Node 是纯粹的目录树对象，完全不知道 Qt 的存在，模型负责在 Node 和 QModelIndex 之间搭桥。实际项目里这里可以换成任何结构：XML 节点、JSON 对象、数据库查询结果的封装，甚至是一张内部哈希表。
3.2 完整代码与关键实现说明
核心映射函数是这一段，我把它拆开讲：
QModelIndex FileTreeModel::index(int row, int column, const QModelIndex &parent) const { if (!hasIndex(row, column, parent)) return QModelIndex(); Node *parentNode = parent.isValid() ? nodeForIndex(parent) : m_root; if (!parentNode || row >= parentNode->children.size()) return QModelIndex(); Node *child = parentNode->children.at(row); return createIndex(row, column, child); }顺序很重要：先做边界检查，再解析 parent，最后 createIndex。特别是 hasIndex 这一步，它能过滤掉大部分无效调用，有它和没它，程序在调试期的报错信息会差很多——少了它，越界访问很容易在 data() 里才暴露，你都不知道问题出在哪个环节。createIndex 的第三个参数存的是内部指针，Qt 只负责原样传递，这个设计让你可以在 O(1) 时间内从 index 反查回业务节点，性能开销几乎为零。
parent() 是树形模型最容易写错的函数，因为根目录对应的 index 是无效的 QModelIndex()，顶层节点的 parent 也是它：
QModelIndex FileTreeModel::parent(const QModelIndex &child) const { if (!child.isValid()) return QModelIndex(); Node *childNode = nodeForIndex(child); Node *parentNode = childNode ? childNode->parent : nullptr; if (!parentNode || parentNode == m_root) return QModelIndex(); Node *grandParent = parentNode->parent; if (!grandParent) return QModelIndex(); int row = grandParent->children.indexOf(parentNode); return createIndex(row, 0, parentNode); }你注意看这里的返回值逻辑：如果某个节点的父节点是根，或者父节点没有爷爷节点，就必须返回无效 index，否则视图会认为这个节点还有父层，树会多出一层来。我第一次写树形模型时在这个函数上栽了跟头，树形结构变成了"每层都多一个空根"，查资料才意识到：当节点位于最顶层时，parent 必须返回 QModelIndex()，而不是给它造一个"假父亲"。
data() 的实现按 role 分发：
QVariant FileTreeModel::data(const QModelIndex &index, int role) const { if (!index.isValid()) return QVariant(); Node *node = nodeForIndex(index); if (!node) return QVariant(); switch (role) { case Qt::DisplayRole: if (index.column() == 0) return node->name; if (index.column() == 1) return node->isDir ? QStringLiteral("-") : formatSize(node->size); break; case Qt::TextAlignmentRole: if (index.column() == 1) return QVariant(Qt::AlignRight | Qt::AlignVCenter); break; case Qt::ToolTipRole: return node->name; // 调试期特别有用，鼠标悬停就能看到原始数据 default: break; } return QVariant(); }这里有三点值得记一下。第一，rowCount 返回子节点数量，但列的数量 columnCount 通常全树一致，所以直接返回一个常量（这里是 2），但要注意某些层级可能列数不同，这时需要按 parent 区分。第二，TextAlignmentRole 这种"非数据"的 role 也非常有用，它可以让大小列右对齐而不用写代理，属于曲线救国的做法。第三，调试期把 ToolTipRole 返回原始数据是个好习惯，悬停一看就知道模型拿到的数据对不对，比打日志快得多。
3.3 接到视图上与调试验证
模型写完之后，接入视图只需要两行：
FileTreeModel *model = new FileTreeModel(this); QTreeView *view = new QTreeView(this); view->setModel(model);挂上去之后，先别急着做美化，我建议按从简到繁的顺序验证：第一步先展开全部节点，确认树的层级正确、行数正确；第二步点击各个节点，确认选择行为正常；第三步把窗口拉大缩小，确认滚动正常。这些基础的验证做完，再去考虑列宽、排序列、样式表这些锦上添花的部分。
如果发现某个深层的父节点下面子节点显示不出来，优先检查 rowCount 是否按 parent 正确区分了层级。我写过一个很隐蔽的 bug：rowCount 内部用了 index 的 row 而不是 parent 来取节点儿子，结果树只显示了第一层，深层节点的子节点被静默忽略了，而且没有任何编译错误或运行时报错，只能靠逐个节点比对数据来定位，相当折磨人。
4. 进阶：把模型做成可编辑、可增删的
4.1 setData 与委托的编辑流程
现在把上面的只读模型升级成可编辑的。编辑的第一步是 flags 要允许编辑，第二步是实现 setData：
bool FileTreeModel::setData(const QModelIndex &index, const QVariant &value, int role) { if (!index.isValid() || !(flags(index) & Qt::ItemIsEditable)) return false; Node *node = nodeForIndex(index); if (!node) return false; if (role == Qt::EditRole) { if (index.column() == 0 && !value.toString().isEmpty()) { node->name = value.toString(); emit dataChanged(index, index, {Qt::DisplayRole, Qt::EditRole}); return true; } } return false; }这里有几个关键点。一是 setData 返回 false 的时机很重要：如果数据没变化，也应该返回 true 还是 false？我的习惯是，值完全相同的时候返回 true 但不发信号，避免无意义的刷新；值非法（比如空字符串）就返回 false，让视图知道编辑被拒绝。二是 dataChanged 的第三个参数是 roles 列表，虽然现在很多 Qt 版本忽略它，但写上是规范的，语义更清晰。
用户双击编辑时，视图默认会用 EditRole 从 data() 取初始值。这就是为什么前面强调 DisplayRole 和 EditRole 要分开——显示的时候可能是"1.2 GB"这种格式化字符串，编辑的时候必须是原始字节数，否则用户一打开编辑框看到的是一串奇怪的缩写。我见过不少新手在这里把显示文本直接拿来编辑，结果编辑完把格式化文本存回去，数据就废了。
4.2 beginInsertRows / beginRemoveRows 的规范用法
增删行是自定义模型里最讲究"仪式感"的部分。Qt 要求你在真正修改内部数据之前调用 beginInsertRows，在修改完成之后再调用 endInsertRows，一对 begin/end 之间绝对不允许让视图发生重入。
bool FileTreeModel::insertRows(int row, int count, const QModelIndex &parent) { Node *parentNode = parent.isValid() ? nodeForIndex(parent) : m_root; if (!parentNode) return false; beginInsertRows(parent, row, row + count - 1); for (int i = 0; i < count; ++i) { Node *node = new Node; node->parent = parentNode; parentNode->children.insert(row + i, node); } endInsertRows(); return true; }为什么要这么设计？因为视图需要在结构变化前记录一些内部状态，比如当前选中的位置、展开状态、垂直滚动条的偏移量。beginInsertRows 给视图一个"准备"的机会，endInsertRows 给视图一个"重建"的机会。如果你跳过 begin/end 直接改数据，再手动发一个 layoutChanged 信号，虽然视图也会刷新，但展开状态和选中状态全丢了，用户体验大打折扣。
同理，removeRows 要先用 beginRemoveRows，改完再 endRemoveRows。删除节点时还要递归删除 children，防止内存泄漏——这个不属于 Qt 模型的要求，但属于你自己数据结构的该做的事。
还有一个容易忽略的细节：在 begin 和 end 之间，视图可能会向你查询一些东西，理论上你不应该在中间做耗时操作。我有一个同事在 beginInsertRows 和 endInsertRows 之间做了数据库同步，结果界面卡顿特别明显，把耗时操作挪到 endInsertRows 之后就好了。
4.3 自定义角色与委托的配合
Qt 内置的 role 就那么几个，真正复杂的模型通常需要自定义 role。比如你的节点可能有优先级字段，你想让高优先级的节点显示成红色，一种做法是在 data() 里判断数据然后返回一个 QBrush 给 Qt::ForegroundRole。如果想做得更灵活，可以定义枚举：
enum NodeRoles { SizeRawRole = Qt::UserRole + 1, IconIdRole = Qt::UserRole + 2, };自定义 role 的好处是让数据的"原始值"和"表现值"彻底分离，代理和搜索逻辑都可以直接用 role 取数据，不用去解析格式化后的文本。比如 SizeRawRole 返回真实的字节数，DisplayRole 返回格式化字符串，排序的时候让视图按 SizeRawRole 排——这样永远不会出现"1.2 GB"被按字符串排序导致 10 GB 排在 2 GB 前面的笑话。
代理（Delegate）在自定义模型里的作用通常是覆盖默认编辑器的行为。默认的编辑框是 QLineEdit，如果你要编辑的是一个下拉选择或者自定义控件，就重写 createEditor、setEditorData、setModelData 这三个函数。setEditorData 是从模型往编辑器灌数据，setModelData 是从编辑器收数据写给模型——它内部会调 setData，所以你的 setData 实现越健壮，代理就越省心。
5. 常见问题与排查技巧
5.1 索引失效：缓存 QModelIndex 的坑
这是自定义模型新手最容易踩的雷。我在前面强调过 QModelIndex 是瞬时地址，一旦模型发生了结构性变化——插入、删除、移动行、甚至某些情况下的布局变化——之前拿到的 index 就可能指向错误的位置甚至已释放的内存。
实际开发中的经验法则是：绝对不要把 QModelIndex 存成成员变量长期使用。如果非要长期保存某个节点的"身份"，我建议用一层间接映射：在模型里维护一个 id 到节点的映射表，代码里只保存 id，每次需要 index 的时候通过 id 查节点再 createIndex。这样即使模型结构变了，只要节点还在，id 就能准确定位。我自己就是这么做的，微信聊天记录那种"需要记住上次浏览位置"的需求，用 id 方案比直接存 index 安全得多。
5.2 数据变了视图没刷新怎么办
表现症状是：模型内部数据改了，视图还停留在旧数据。这时候按优先级排查三件事：第一，有没有发 dataChanged（数据值变了但行列没变）；第二，有没有发 beginInsertRows/endInsertRows（行数变了）；第三，有没有发 layoutChanged（结构布局整体变了）。
我曾经在实现"过滤显示满足条件的行"功能时，把所有不符合条件的行直接删除，结果视图频繁闪烁，后来改成用 setRowHidden 配合恢复保留，就顺滑多了。这其实牵出一个通用原则：能用"局部信号"解决的，绝不用"全局信号"；能不动结构就不动结构，因为每次结构变化，视图都要经历一次较重的重建流程。
还有一个绕不开的场景：数据在非 UI 线程更新了，然后跨线程触发视图刷新。Qt 不允许在非主线程直接调用模型的信号，正确做法是通过信号/槽的直连或队列连接，让主线程来发 dataChanged。我见过有人用全局指针在子线程直接 emit，那种做法轻则界面崩溃，重则程序偶发非法内存访问，排查起来极其恶心。
5.3 大数据量下的性能优化
自定模型最大的优势之一就是性能潜力。默认实现里，视图只显示可见区域，所以 data() 只被调用几十次，而不是全部数据里调一遍。但如果你在 data() 里做了一些看似很小的操作，比如字符串格式化、正则匹配、动态查数据库，数据一多照样卡。
优化思路按优先级来：第一，数据尽量预计算，显示用的格式化字符串在数据进入模型时就建好，不要在 data() 里现算；第二，给高频调用的函数加缓存，比如 nodeForIndex 这种通过指针直接映射的函数本身就够快，但如果你用哈希表反向查询就要注意瓶颈；第三，canFetchMore / fetchMore 这对接口用于实现懒加载，树形结构很深的时候非常好用——视图显示到哪个分支，才去加载哪个分支的子节点，几千个目录的树也能秒开。
我做一个日志分析工具时就吃过亏：300 万行日志直接塞进模型，虽然模型没崩，但每次点击一个节点都要等半秒才响应，后来发现是 data() 里对每行日志都做了一次格式解析和正则匹配。把解析结果缓存到结构体后，界面响应立刻回到丝滑级别。性能问题往往不是模型框架的错，是你在模型里干了太多不该干的事。
5.4 验证工具：QAbstractItemModelTester
写自定义模型最难受的是，很多 bug 在编译期完全看不出来，只能在运行时通过奇怪的界面行为暴露。Qt 提供了一个自动化验证工具 QAbstractItemModelTester，专门用来校验模型的实现是否符合规范。
它会在模型每一次 signal 发出后做一致性检查，比如 rowCount、index、parent、data 这些函数是否满足"不变式"（invariant），比如：
- index 返回的节点行号必须小于 rowCount。
- parent(index) 和 index 之间必须有正确的层级关系。
- 所有返回的 index 通过 data 访问都不能崩溃。
- 数据结构变化信号的参数区间必须合法。
用法非常简单，构造一个模型实例和 tester 绑定即可：
FileTreeModel *model = new FileTreeModel(this); QAbstractItemModelTester tester(model, QAbstractItemModelTester::FailureReportingMode::Fatal);把 tester 放到测试工程里跑一遍，配合模型的随机增删操作，比自己肉眼盯着界面找 bug 高效得多。它背后其实就是一系列断言，是我写自定义模型时的必备武器。
5.5 两个我亲身踩过的坑
分享两个真实踩过的坑，希望能帮后来者省点时间。
第一个坑发生在树形模型的 removeRows 里。我当时只做了 beginRemoveRows / endRemoveRows，删除子节点时忘了递归释放 child 的 children，导致内存泄漏。调试工具一排泄漏几十个 Node，一度让我以为是模型本身的问题。后来我才意识到 begin/end 只管通知视图，数据结构的内存管理永远是你自己的责任。解决方式是在 Node 析构函数里释放所有 children，析构一处搞定，再也不会忘。
第二个坑出现在自定义模型的排序功能上。我重写了 sort()，但在排序后没有调用 beginResetModel / endResetModel，结果视图里的行位置和模型内部数据的顺序发生了错位，点击某一行选中的却是另一行的数据。后来查资料才知道：排序是一种特殊的结构变化，视图需要知道"整张表被重排了"，要么用 beginResetModel/endResetModel 通知全量重置，要么就发 layoutAboutToBeChanged / layoutChanged 并且在中间维护好持久索引。这俩方案我最终选了后者，因为重置会让展开状态全丢。
最后再分享一个我个人的小习惯：所有自定义模型，不管多简单，我都会在构造函数里把 QAbstractItemModelTester 加上，把它挂在测试用例里而不是生产代码里。原因很简单——模型里的 bug 往往不是"一次性的逻辑错误"，而是"某种特定操作顺序触发的不变式破坏"，比如先插入再删除再插入，这种组合逻辑靠人眼很难覆盖，用 tester 能自动发现一大半。写模型这件事，只要把索引映射和信号广播这两件事做对了，剩下的无非是耐心调试而已。
建模与Matlab实现)
