Cloud Function首次调用偶发返回Firestore旧数据，是否为缓存问题及如何解决

核心根因 #

你遇到的偶发旧数据问题本质是Firestore快照监听器的触发逻辑导致的：snapshots() 监听器首次启动时会优先返回本地缓存的历史快照，同时后台异步同步服务端最新数据。如果此时你立刻调用云函数，要么是本地缓存的旧数据触发了无效调用，要么是本地刚产生的变更还没同步到服务端，云函数查询服务端时自然拿不到最新状态。加500ms延迟刚好等同步完成所以能临时规避，但通过逻辑判断就可以彻底解决。

修复步骤 #

1. 过滤监听器的无效触发事件 #

在客户端监听器中新增快照元数据判断，跳过未完成服务端同步的本地快照，只有确认拿到服务端最新数据后再调用云函数：

firestore.collection("users")
          .doc(uid)
          .collection("notifications")
          .snapshots()
          .listen((QuerySnapshot querySnapshot) {
            // 跳过本地缓存、存在待同步写入的快照，只处理服务端同步完成的事件
            if (querySnapshot.metadata.isFromCache || querySnapshot.metadata.hasPendingWrites) {
              return;
            }
            NotificationsPreviewModel notificationsPreview =
                await _cloudFunctionsService.getNotificationsPreview(doctor.id);
          })

这个改动可以100%规避首次加载旧缓存触发的异常调用，后续的变更触发都是服务端主动推送的同步后数据，不会再出现时间差问题。

2. （可选）优化云函数查询性能 #

你当前的云函数是全量拉取通知集合后再过滤未读、截断，数据量大时会浪费Firestore读配额，可直接把过滤条件放到查询层，同时用count聚合接口统计总数，降低执行耗时：

exports.getNotificationsPreview = functions.https.onCall(async (data, context) => {
    const userId = data.userId;
    // 直接在查询阶段过滤未读、按时间倒序
    const notificationQuery = db
        .collection("users")
        .doc(userId)
        .collection("notifications")
        .where("unread", "==", true)
        .orderBy("dateTime", "desc");
    // 并行查询前3条数据 + 未读总数，不用拉取全量文档
    const [notificationSnapshot, countSnapshot] = await Promise.all([
      notificationQuery.limit(3).get(),
      notificationQuery.count().get()
    ]);
    const notifications = notificationSnapshot.docs.map(doc => doc.data());
    const notificationsNumber = countSnapshot.data().count;
    return { notifications, notificationsNumber };
});

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