如何在Firestore中删除文档并维护高效同步的数据库模型？

你提到的基于last_modified字段的增量同步方案，确实能有效降低读取量，但它天然无法捕捉文档删除事件——因为已删除的文档不会出现在查询结果里。针对这个问题，以下是几种可行的解决方案：

方案1：维护删除操作日志集合 #

• 创建一个独立的集合（比如document_deletions），每次在Firestore中删除文档时，同步向这个集合添加一条记录，包含以下字段：
  • doc_id: 被删除文档的ID
  • collection: 被删除文档所属的集合名称
  • deleted_at: 删除时间戳（和last_modified格式一致）
• 每次同步时，除了执行last_modified > lastQueried的新增/修改查询，额外执行deleted_at > lastQueried的查询，获取这段时间内的删除记录，然后在本地数据库中删除对应ID的文档。
• 注意：可以给deleted_at字段建立索引，保证查询效率；另外可以定期清理这个集合里的旧记录（比如超过30天的删除日志），避免存储冗余。

方案2：利用Firestore快照监听器 #

• 如果你的业务场景支持实时同步，可以直接使用Firestore的快照监听器（Snapshot Listeners）。监听器会主动推送三种事件：文档新增、文档修改、文档删除。
• 初始同步时，先用last_modified > lastQueried拉取历史增量数据；之后保持监听器运行，实时处理所有变更事件，包括删除。
• 如果是间隔式同步（比如每天同步一次），也可以在同步时临时开启监听器，获取上次同步到当前的所有变更，处理完成后关闭监听器，平衡实时性和资源开销。

方案3：定期全量ID校验 #

• 针对删除操作不频繁的场景，可以保留原有的增量同步逻辑，同时定期（比如每周一次）执行一次轻量全量校验：
  1. 全量拉取云端集合的所有文档ID（注意：只拉取ID，不拉取文档内容，读取成本远低于全量读取文档）
  2. 对比本地数据库的文档ID列表，找出本地存在但云端没有的ID，删除本地对应文档
• 这种方式既能维持日常低读取成本的增量同步，又能定期清理本地的无效数据，适合删除操作较少的业务场景。

关于初始设计的分析 #

你的初始设计本身没有缺陷，它是增量同步场景下的标准方案之一，但它的适用范围有限——仅适合删除操作极少或完全没有的业务场景。如果你的业务中存在频繁的删除需求，就需要补充上述任意一种处理删除事件的机制，才能让同步逻辑完整。

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