Firestore查询结果是否真的需要检查文档存在性？

很多用PHP SDK做Firestore开发的人都会纳闷：官方示例里明明是从数据库条件查询出的文档列表，为什么遍历每个结果的时候还要特意套一层$document->exists()判断？难道从查询返回的结果里，还能冒出来根本不存在的文档？

这真不是官方写示例多此一举，背后对应着几个实际运行时确实会碰到的场景：

• 分布式读写的时序错位问题
  Firestore 是分布式架构的数据库，做不到毫秒级的强一致同步。你发起一次条件查询时，数据库的执行流程分两步：先把集合里所有符合查询条件的文档ID扫出来列成清单，再按清单挨个拉取对应ID的具体文档内容返回。这两步之间哪怕只有几毫秒的空隙，都有可能撞上别的客户端刚好把清单里的某个文档删掉。等轮到读这个被删掉的文档时，拿到的就是个没有实际内容的空快照，exists()自然就会返回false。
• SDK 统一API的兼容设计
  为了降低开发者的记忆成本，PHP SDK对所有文档读取操作的返回类型做了统一：不管你是直接按已知文档ID查单个文档（这类查询天然就会碰到文档不存在的情况，比如你要查的ID压根没建过），还是按条件查一整个集合的匹配结果，遍历拿到的每一项都是同一个DocumentSnapshot类的实例。既然类型是统一的，快照对象上的exists()方法也会完整保留，不会因为是批量查询就把这个判断逻辑去掉。
• 离线缓存的快照过期问题
  如果你的应用开了Firestore的本地持久化缓存，执行查询时SDK会优先读本地存的历史数据快速返回，不等云端同步。这时候本地缓存里记录的某条文档，可能对应的线上版本早就被删了，只是还没等到下次联网时把本地缓存的条目更新掉，这种场景下拿到的快照同样会显示文档不存在。

平时开发很少碰到不存在的分支，本质上是因为时序错位、缓存过期的发生概率很低，但不代表这类情况完全不会出现。官方要求做存在性校验，就是给这类低概率的异常场景留好兜底的处理出口。

顺带提一句：官方给的PHP示例代码里有个小笔误，else分支里写的是$snapshot->id()，这个变量从头到尾没被定义过，正确写法应该是$document->id()，不少人直接抄示例代码的时候都会踩这个未定义变量的坑。

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