如何在QAbstractItemModel的begin/end函数外正确修改底层数据结构？

你遇到的这个场景太典型了——当底层数据模型和Qt视图绑定的QAbstractItemModel子类完全分离，外部代码直接修改底层数据时，很容易打破Qt模型要求的begin/end调用规范，导致索引指向已销毁的实体，触发崩溃或异常。下面给你几个实用的解决方案：

方案1：给底层数据的修改加“Qt模型同步包裹” #

如果底层数据是你自己维护的，最稳妥的方式是强制所有影响结构的修改都通过统一接口进行，在这些接口里自动同步Qt模型的状态：

• 给底层数据模型的addChild、removeChild这类方法，嵌入Qt模型的begin/end调用逻辑：

  void CoreTreeModel::removeChild(Item* parent, int row) {
      // 先通知Qt模型准备删除行
      auto qtModel = m_qtProxyModel;
      auto parentIndex = qtModel->indexFromItem(parent);
      qtModel->beginRemoveRows(parentIndex, row, row);
      
      // 实际修改底层数据结构
      parent->children().removeAt(row);
      
      // 完成Qt模型的状态同步
      qtModel->endRemoveRows();
  }
  

• 这样不管哪个模块调用底层数据的修改，都能自动触发Qt模型的正确更新，从根源避免索引失效。

方案2：延迟同步+标记过滤处理外部硬修改 #

如果实在没法控制底层数据的修改（比如依赖第三方库或其他模块直接操作），可以用“软标记+延迟清理”的方式：

• 当底层数据发出变更信号时，不要立刻删除Qt模型的索引，而是给对应的实体打上“待销毁”标记；
• 在Qt模型的rowCount()、data()、index()等核心方法里，自动忽略这些标记为无效的项；
• 用QTimer::singleShot(0, this, [this](){ /* 执行清理 */ })在事件循环空闲时，再调用beginRemoveRows/endRemoveRows批量清理无效索引，同时删除底层数据里的废弃实体；
• 额外维护一个Item*到QModelIndex的映射表，每次Qt模型更新时同步更新映射，这样能快速定位需要处理的索引范围，不用遍历整个模型。

方案3：让Qt模型成为底层数据的唯一入口 #

把Qt模型设计成底层数据的“代理层”，外部模块所有对底层数据的修改请求都先经过Qt模型：

• 外部代码不要直接操作底层数据，而是调用Qt模型的接口，比如qtModel->removeItem(parentIndex, row)；
• 在Qt模型的接口里，严格遵循begin/end规范：先调用beginRemoveRows，再修改底层数据，最后调用endRemoveRows；
• 同时在底层数据修改完成后，触发它自己的变更信号，通知其他依赖模块。
  这种方式既满足了Qt的模型规范，又能保证底层数据的变更能同步到其他模块。

关键避坑点 #

• 绝对不要在begin/end调用之外直接修改底层数据后通知Qt模型，这会彻底破坏Qt模型的状态一致性，轻则索引失效，重则触发崩溃；
• 如果是批量修改（比如一次删除多个子项），一定要用beginRemoveRows的起始/结束索引批量处理，不要循环单个调用，否则会严重拖慢UI性能。

内容的提问来源于stack exchange，提问作者Target-san