Firestore请求firestore.googleapis.com过久阻塞其他请求如何解决

你看到的这个挂起很久的firestore.googleapis.com请求不是异常脏请求，是Firestore SDK初始化阶段默认触发的本地缓存与云端的全量一致性同步任务，SDK默认把该任务放在请求队列最高优先级，才会阻塞后续业务读写请求。根据你的需求选对应处理方式即可：

方式一：彻底移除该阻塞请求 #

如果你的业务不需要离线可用能力，初始化Firestore时直接关闭持久化缓存，这个同步任务就不会生成：

// Web SDK v9+ 示例
import { initializeFirestore, memoryLocalCache } from "firebase/firestore";

// 初始化时指定使用内存缓存，关闭本地持久化
const db = initializeFirestore(firebaseApp, {
  localCache: memoryLocalCache()
});

如果是Android/iOS/Flutter等移动端SDK，初始化时把persistenceEnabled参数设为false即可达到同样效果。

方式二：保留离线能力，调整请求优先级 #

如果需要离线持久化功能，可以通过配置降低该同步任务的优先级，让核心业务请求先执行：

• 初始化Firestore时关闭默认的全量集合同步逻辑，只同步当前页面主动监听的数据集：

  import { initializeFirestore, persistentLocalCache, CACHE_SIZE_UNLIMITED } from "firebase/firestore";
  
  const db = initializeFirestore(firebaseApp, {
    localCache: persistentLocalCache({
      cacheSizeBytes: CACHE_SIZE_UNLIMITED,
      synchronizeTabs: true
    }),
    // 关闭流式拉取，避免长连接占用通道阻塞小请求
    useFetchStreams: false
  });
  

• 不要在应用初始化阶段直接注册无过滤条件的全集合监听，等核心业务的读写、单文档/带条件的小范围查询请求发起完成后，再注册非核心的全量同步监听。
• 非核心路径的数据查询优先加source: 'cache'配置先读本地缓存，等页面空闲后再触发网络同步，不抢占核心请求的连接资源。

额外排查项 #

如果关闭持久化后依然存在这类长耗时阻塞请求，直接检查初始化阶段的代码：有没有写无where条件、无limit限制的全集合getDocs查询，这类全表扫描请求本身耗时就极长，直接加查询条件、分页逻辑或者移到非核心时机触发即可。

内容的提问来源于stack exchange，提问作者김태형 Tae