使用两次查询的方案能否有效降低Firestore的文档读取次数？

方案可行性结论 #

这个方案整体可行，核心的增量同步+本地缓存逻辑确实可以大幅降低Firestore的读请求计费，相比每次全量拉取100+文档的旧方案，优化效果非常明显。

方案核心优势 #

• 仅首次打开App、或是用户清空App缓存后需要全量拉取100+次读请求，后续每次打开仅拉取上次拉取时间后变更的文档，通常只会产生个位数甚至0次读计费，成本控制效果显著
• Firestore服务端查询返回的结果会自动合并到本地离线缓存中，不需要手动处理增量数据的写入和合并，实现成本极低

需要修正/注意的边界问题 #

• updated_at字段必须使用Firestore服务器时间戳FieldValue.serverTimestamp()写入，禁止使用客户端本地时间赋值，避免客户端时钟偏移导致增量拉取漏同步更新的文档
• 新增首次启动判断逻辑：如果本地没有存储的lastUpdatedAt记录（用户首次使用/清除了App缓存），直接全量拉取服务端所有tasks文档完成首次缓存初始化，避免出现首页列表为空的问题
• 处理文档删除场景：当前逻辑无法同步硬删除的文档，被删除的文档会一直残留在本地缓存中导致数据不一致，推荐用软删除方案替代硬删除：给tasks文档新增is_deleted布尔字段，删除操作仅更新文档将is_deleted设为true同时更新updated_at，本地构建列表时过滤掉is_deleted=true的文档即可
• 本地存储的lastUpdatedAt需要和缓存状态绑定：如果监听到Firestore缓存被清空、或者用户清除App数据时，同步清空存储的lastUpdatedAt值，避免缓存缺失时仅拉取增量导致列表数据不全

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