React Native使用react-native-firebase时getDownloadURL调用触发多请求致带宽异常

提问核心背景：

• 业务逻辑：仅在首页useEffect中执行1次getDownloadURL调用，获取用户头像下载链接后更新全局状态
• 业务实现代码：

import auth from "@react-native-firebase/auth";
import storage from "@react-native-firebase/storage";

const uid = auth().currentUser.uid;
//Setting dp from storage
  const dp = await storage().ref(`/profiles/${uid}/0`).getDownloadURL();
  dispatch({ type: SET_DP, payload: dp });

• 当前配置的Storage安全规则：

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read: if request.auth != null;
      allow write: if request.auth != null;
    }
  }
}

• 异常现象：应用启动阶段会向Firebase Storage发起5次以上请求，造成带宽消耗异常升高。

冗余请求的实际来源 #

观测到的多请求并非业务代码重复触发，全部来自SDK内置机制，具体包括：

• Storage请求的自动重试逻辑：SDK对所有Storage元数据请求默认配置了最多5次的重试策略，当请求遇到临时网络波动、鉴权令牌未就绪、规则校验临时失败时，会自动发起重试，这类请求不会在业务层返回错误，仅会在网络请求面板中留下记录。
• 鉴权令牌刷新的关联重发：当前安全规则要求所有请求必须通过request.auth != null校验，当SDK检测到本地存储的用户ID token临近过期时，会先触发令牌刷新，之前因令牌不匹配被中断的Storage请求会在令牌刷新完成后自动重发，这部分逻辑不会绑定业务层的await回调。
• 模块初始化连通性探测：Storage模块首次实例化时，会自动向默认配置的存储桶发起一次元数据请求，校验存储桶配置的连通性，这个请求完全独立于首页useEffect中的getDownloadURL调用，不会产生任何业务侧返回值。
• 图片组件的缓存重试：获取到下载URL后如果直接绑定到RN的Image组件，Image组件在缓存未命中、临时加载失败的场景下，会自动发起额外的图片资源拉取请求，这部分流量同样会被计入Firebase Storage的请求量中。

可落地的优化手段 #

• 收敛SDK重试配置：初始化Storage实例时，将单请求的最大重试次数限制为1，减少因临时异常触发的重复请求。
• 前置完成鉴权令牌刷新：在调用任何Storage接口前，主动执行await auth().currentUser.getIdToken(true)确保有效令牌就绪，避免后续Storage请求因令牌过期触发重试。
• 收窄安全规则匹配范围：将当前全路径开放的读写权限调整为仅匹配实际业务用到的/profiles/{uid}/**路径，减少规则校验环节的冗余请求开销。
• 关闭模块连通性探测：在初始化Storage模块时传入配置参数，禁用默认的存储桶连通性检查，消除无业务价值的探测请求。

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