Strapi历史/修订模型设计咨询：多对多关系处理方案

我之前帮几个客户落地过类似的Strapi历史版本功能，针对你遇到的直接复制模型带多对多关联导致异常的问题，核心症结在于：Strapi的关联机制依赖中间表维护关系，历史版本的关联会和当前实体的关联池混在一起，进而引发数据混乱。下面给你两种经过验证的方案，兼顾关系完整性和版本对比需求：

方案一：通用型历史记录表（推荐，更灵活） #

不用给每个实体单独创建历史模型，而是做一个通用的revision-history模型，统一存储所有实体的修订记录，结构如下：

关键优势： #

1. 避免关联冲突：所有关联数据都以JSON形式快照存储，不依赖Strapi的关联中间表，彻底解决原方案的关系损坏问题。
2. 版本对比友好：revisionData的结构和原实体的返回结构完全一致，直接拿当前实体数据和历史快照做diff即可（前端用diff-match-patch这类库就能实现高亮差异）。
3. 扩展性强：后续新增实体类型不需要再创建新的历史模型，直接扩展entityType的枚举值就行。

触发修订记录的方式： #

在每个需要追踪历史的实体模型中，通过生命周期钩子自动生成快照。比如在publication模型的afterUpdate和afterCreate钩子中：

module.exports = {
  lifecycles: {
    async afterCreate(result) {
      await this.createRevision(result.id);
    },
    async afterUpdate(result) {
      await this.createRevision(result.id);
    },
    async createRevision(entityId) {
      // 获取完整的实体数据（包括关联的cooperations）
      const fullEntity = await strapi.query('publication').findOne({ id: entityId }, ['cooperations']);
      // 生成关联数据的快照（如果需要保留关联实体当时的状态，就存完整数据，否则存ID列表）
      const cooperationSnapshot = fullEntity.cooperations.map(coop => ({
        id: coop.id,
        name: coop.name,
        // 其他你需要保留的字段
      }));
      // 移除原实体的关联对象，替换为快照
      const revisionData = {
        ...fullEntity,
        cooperations: cooperationSnapshot
      };
      // 创建历史记录
      await strapi.query('revision-history').create({
        entityType: 'publication',
        entityId,
        revisionData,
        revisionNumber: (await strapi.query('revision-history').count({ entityId, entityType: 'publication' })) + 1,
        createdBy: strapi.user?.id || null
      });
    }
  }
};

方案二：实体专属历史表（适合需求单一的场景） #

如果必须给每个实体单独创建历史模型（比如publication-history-entry），核心原则是移除所有Strapi原生的关联字段，换成静态的JSON/数组字段存储关联信息：

1. 复制原模型的所有普通字段：比如标题、描述、日期等直接复制到历史模型中。
2. 替换关联字段：把原模型中类似cooperations: { collection: "cooperation", ... }的关联，改成cooperationIds（数组类型）或者cooperationSnapshot（JSON类型），存储修订时的关联ID列表或完整快照。
3. 添加元字段：给历史模型加上revisionNumber、createdBy、createdAt这些版本追踪必备字段。

注意事项： #

• 历史模型的所有字段都设为只读：在Strapi的权限设置中，只允许后台钩子创建记录，禁止普通用户修改/删除。
• 不要在历史模型中创建任何collection/model类型的关联，所有关联数据都静态存储，避免和当前实体的关联池冲突。

版本对比的实现思路 #

无论是哪种方案，版本对比的核心都是结构化数据的差异对比：

1. 从历史表中取出目标版本的revisionData（或专属历史表的字段）。
2. 获取当前实体的完整数据结构。
3. 用diff工具（后端用deep-diff，前端用diff-match-patch）对比两个JSON对象，生成差异报告后渲染到页面即可。

比如前端可以这样展示差异：把不同的字段用红色（删除）和绿色（新增）高亮，关联实体的变化也能通过快照数据清晰展示。

内容的提问来源于stack exchange，提问作者Sebastian Jung