系列循环事件单个 occurrence 独立编辑删除的实现思路探讨

这套方案完全兼容主流的循环事件存储设计，不需要全量预生成所有循环实例，从根上解决单实例编辑、删除、附加备注的独立处理需求，存储和查询效率远高于全量预生成的方案。

核心设计思路 #

你完全不需要为每一个循环实例单独存储一行——绝大多数循环生成的实例都完全符合父事件的默认规则，没有任何自定义改动，预生成全量实例只会带来无意义的存储开销（尤其是长周期、高频循环的事件，比如每日早会类事件，长期运行后数据量会无意义膨胀）。
用户对单个循环实例的删除、修改、加备注三类操作，本质都是偏离父规则默认输出的例外项，完全不需要和父事件的核心配置强绑定，只需要单独存储这些偏离的部分即可。

配套存储结构 #

在原有父循环事件表（存储基础标题、默认时间、RRULE循环规则、结束条件、默认地点等通用元数据）的基础上，新增一张「单实例例外表」，核心存储字段的设计逻辑如下：

• 关联父事件的唯一标识：用于定位该例外属于哪个循环系列
• 例外的原始触发时间锚点：这是匹配单实例的核心标识——不管后续对这个实例做什么修改，这个值永远记录它最初由父规则计算生成时的原始时间，用来精准识别“操作的是循环系列里的哪一个具体实例”，不会和其他实例混淆
• 例外类型标记：区分该例外是“删除某实例”、“修改某实例属性”、“给某实例附加备注信息”三类
• 自定义覆盖属性：只存储被用户修改过的字段值（比如改了时间就存新的时间、改了地点就存新地点），未被修改的字段不需要存储，运行时直接沿用父事件的默认值即可
• 附加信息字段：专门存储单实例独有的备注、附件、自定义标签等内容，和父事件的通用配置完全隔离，满足给特定实例加备注的需求

运行时的实例生成流程 #

当需要查询指定时间范围内的所有日历事件时，按照以下流程拼接最终的事件列表：

1. 先根据每个父事件的RRULE规则，计算出查询时间范围内的所有默认实例，为每个实例绑定对应的原始触发时间锚点
2. 批量取出「单实例例外表」中，和当前查询范围内父事件关联的所有例外记录
3. 以「父事件ID + 原始触发时间锚点」为匹配键，将计算出来的默认实例和例外记录做一一匹配，按类型处理：
   • 例外类型为删除：直接剔除对应的默认实例，不展示在最终列表里
   • 例外类型为属性修改：用例外记录里存储的自定义覆盖属性，替换掉默认实例的对应字段，未被覆盖的字段保留父事件的默认值
   • 例外类型为附加备注：将备注内容绑定到对应的默认实例上，不改动任何原有默认属性
4. 对修改后时间落在查询范围内的例外实例，单独加入最终的事件列表，不受原父规则的计算范围限制

边界场景的通用处理逻辑 #

• 如果用户修改了某个实例的时间，修改后的实例不会触发自身的循环逻辑——它只是一个独立的单条记录，没有绑定任何循环规则，和原父事件只保留溯源关联，不会反向影响循环系列的默认生成结果
• 如果用户需要将某个已经做过修改的实例恢复为默认状态，只需要删除「单实例例外表」中对应的记录即可，实例会自动回到父规则的默认输出状态
• 如果用户需要重复编辑同一个实例的属性（比如第一次改了时间，第二次再加备注），只需要更新对应例外记录的内容即可，不需要重复生成新的例外条目
• 针对已经超出父规则结束范围的历史例外，不需要做特殊清理，查询时只需要根据例外记录的实际时间判断是否落在查询范围即可

*和全量预生成所有实例的方案相比，这套逻辑的存储成本和自定义例外的数量正相关，和循环系列的总实例数完全无关——哪怕一个循环系列有上万个自动生成的默认实例，只要只有不到10个被单独修改过，整体只需要存10条例外记录即可，不会随着循环时间变长出现无意义的数据膨胀。

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