Firestore活动文档快照监听器导致集合排序查询结果异常

• Firestore本地缓存共享特性：当你为users集合的指定文档开启活跃监听器后，该文档会被存入Firestore统一的本地离线缓存池。同集合的新查询会优先复用本地缓存的已有数据作为第一帧快照推送，此时仅包含被单文档监听器持有的1条缓存记录；服务端的完整查询结果返回后会再推送第二帧快照。
• 代码逻辑缺陷：当前onSort方法用Promise包裹onSnapshot回调，第一次触发时就直接resolve并赋值列表，没有区分快照来源，直接把仅包含1条缓存数据的第一帧当成最终结果，导致页面只显示1条记录。
• 退订单文档监听器后功能恢复正常，是因为退订后该文档不再被活跃监听器持有，排序查询的本地缓存没有可复用的单条数据，第一帧推送直接就是服务端返回的完整20条排序结果。

方案1：仅采用服务端返回的快照（推荐） #

通过判断快照的fromCache元数据，忽略本地缓存推送的第一帧，仅当快照来自服务端时再返回结果，修改后的onSort核心逻辑如下：

const users1: { users: any, last: any } = await new Promise((resolve, reject) => {
  this.first = queryRef.onSnapshot((doc) => {
    // 跳过本地缓存推送的快照，仅处理服务端返回的结果
    if (doc.metadata.fromCache) return;

    const users = doc.docs.map(t => ({
      id: t.id,
      ...t.data() as any
    }))
    resolve({
      users,
      last: doc.docs[doc.docs.length -1]
    })
  });
})

完全避免缓存的单条数据插入，等服务端返回完整排序结果后再更新页面。

方案2：单次拉取时强制读取服务端 #

如果排序操作仅需要获取一次排序结果、不需要实时监听列表变更，直接使用get()方法替代onSnapshot，强制指定数据源为服务端：

// 替换原有onSnapshot的Promise包裹逻辑
const querySnapshot = await queryRef.get({ source: 'server' });
const users = querySnapshot.docs.map(t => ({
  id: t.id,
  ...t.data() as any
}));
const users1 = {
  users,
  last: querySnapshot.docs[querySnapshot.docs.length -1]
};

该方式不会读取本地缓存，直接返回服务端符合limit(20)条件的完整排序结果。

方案3：保留预加载体验 #

如果希望利用本地缓存实现快速首屏加载，可调整列表更新逻辑：去掉this._users$.next([])的预清空逻辑，本地缓存推送的单条数据先作为占位显示，等服务端完整结果推送后自动替换列表内容，兼顾加载速度和结果准确性。

补充说明：你观察到的查询结果与其他文档监听器存在关联，是Firestore离线缓存的预期设计，同集合的所有查询共享同一套本地缓存池，不存在完全隔离的查询逻辑。如果需要严格的服务端结果一致性，通过fromCache判断或指定source: 'server'即可完全解决。

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