使用邮箱密码认证时，预期的providerData格式是什么？

这是Firebase Auth针对邮箱密码认证的正常设计行为，并非bug，下面给你拆解原因和处理方案：

为什么会出现这些异常字段？ #

Firebase的providerData数组在处理不同登录方式时，字段表现有差异：

• 对于邮箱密码登录的用户，对应的provider条目里providerId固定为password（这是Firebase用来标识登录方式的字符串，和用户实际密码无关）
• email字段会显示为null，反而phoneNumber会被填充为用户的邮箱地址（这是Firebase的历史遗留设计，确实反直觉）
• displayName会被设为用户邮箱，因为邮箱密码登录默认不强制设置昵称字段

正确的处理方式 #

不要依赖providerData里的字段来获取邮箱密码用户的核心信息，直接从userAuth顶层字段取才是准确的：

1. 获取用户邮箱：直接用userAuth.email，这个字段始终是正确的
2. 判断登录方式：检查userAuth.providerData中对应条目的providerId是否为password，或者直接用userAuth.providerId（单登录方式下）
3. 统一处理多登录方式的信息：可以写个简单的工具函数来标准化数据，避免字段混乱：

function normalizeUserAuthData(userAuth) {
  const normalized = {
    uid: userAuth.uid,
    email: userAuth.email,
    displayName: userAuth.displayName || userAuth.email,
    authProviders: []
  };

  userAuth.providerData.forEach(provider => {
    switch(provider.providerId) {
      case 'password':
        normalized.authProviders.push('email-password');
        break;
      case 'google.com':
        normalized.authProviders.push('google');
        // 谷歌登录的昵称优先取providerData里的
        if (!normalized.displayName) normalized.displayName = provider.displayName;
        break;
      // 其他登录方式比如Facebook、Apple同理
    }
  });

  return normalized;
}

存储到Firestore的建议 #

不要直接存储整个providerData数组，而是存储标准化后的字段（比如上面函数返回的uid、email、displayName、authProviders），这样既避免了异常字段的干扰，也更方便后续查询和布局调整。

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