断线重连时补齐遗漏事件

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

任务事件流断线后，界面需要补回遗漏消息且不能重复更新订单。教学历史返回 e1=开始、e2=完成，新流也返回 e2=完成；事件 ID 稳定，历史可分页查询。重复的完成事件仍须让消费者停止。

具体做法

1. 按接口契约建立并确认新流已打开，再拉取完整的可用历史，检查分页失败与保留期。
2. 按所需顺序处理历史；未见过的 ID 才触发一次处理。记录成功处理进度，不能把失败处理简单标为完成。
3. 消费实时流，去重只包住业务处理；终止判断在它外面，每个事件都执行。历史中的终态也要按宿主生命周期规则处理。
4. 若历史不完整、缓冲溢出或顺序不能满足消费者，报告恢复缺口并采用重建策略，不能声称补齐成功。

反例

订单事件流重连后直接从现在继续。为防重复，遇到已见 ID 立刻 continue，最后再检查完成状态。

改进写法

恢复这条订单流：先确认新流打开，再读取所有可取得的历史页，处理 e1 和 e2。实时尾流里的 e2 不重复更新订单，但照常检查完成状态并结束消费。输出处理ID、停止原因和无法覆盖的时间区间；历史请求失败时不报告完整恢复。

为什么这样改

先开流再读历史，让两个读取区间重叠；ID 去重消除重叠带来的重复处理。生命周期检查独立于去重，避免历史中已出现的终态在实时流中被 continue 吞掉。

如何验证

教学轨迹应记录处理 e1、e2 各一次，以及实时重复 e2 的终态检查和停止。另注入历史第二页失败：结果应标为恢复未完成。检查日志中的顺序、分页和重复事件，不仅看最终界面是否显示完成。

适用边界

须确认具体接口的打开时机、缓冲、排序、稳定 ID、保留期与空闲/终态含义。冻结来源各语言示例的处理和停止逻辑并不完全一致，不能直接视为投递保证。进程崩溃后的持久去重与事务性副作用另需设计；无法恢复历史中不存在的事件。