收到事件不等于状态完整
Telegram 使用 pts、qts、seq 等状态检查更新连续性；不同更新流的规则不同。发现缺口时，按文档调用对应差分方法，频道与普通更新不能共用一套假定的游标。
恢复期间仍可能收到新更新，需要协调缓冲与差分合并。完整算法和各类容器的处理顺序见官方 Working with Updates。
建议的处理边界
将“接收事件”“更新本地状态”“产生产品通知”分开。一次数据库事务内提交业务数据和处理游标；只有事务完成后，才把任务标记为已处理。业务副作用再使用单独的幂等标识。
例如，客服新消息可以重复投递到处理器，但不应因此连续给同一条消息发出多次通知。消息已删除或编辑也不能只当成一条新消息追加。
验证恢复能力
在隔离测试账号上检查：短暂断网、同一更新重复到达、差分恢复中再次断网、应用重启以及多个频道同时更新。检查最终状态而不只看接口返回成功。使用 TDLib 时，应优先消费它提供的更新，不再自行叠加一套未验证的 MTProto 恢复算法。