IONIC结合Angular与Firebase开发登录时偶现emailVerified空值报错

触发根因 #

• 首先纠正一个排查方向：你怀疑的isLoggedIn计算属性实际做了user !== null的短路判断，不会触发该报错，真正直接抛错的是同服务里的isEmailVerified计算属性——它在读取localStorage用户值后，没有对空值做任何判断，直接访问user.emailVerified属性，只要读取到的用户值为null，就会立刻触发报错。
• 报错的时序完全匹配你描述的「二次点击即可正常登录」的现象：
  1. 用户首次点击登录按钮时，调用SignIn方法发起的Firebase认证请求是异步执行的，从请求发出到认证成功、触发authState回调、把用户信息写入localStorage存在数百毫秒的网络延迟。
  2. 在这个延迟窗口里，页面/路由的权限校验逻辑已经执行，此时localStorage里留存的还是上一次登出后的空值，被isEmailVerified方法读取到null后直接抛错。
  3. 等用户第二次点击登录按钮时，第一次发起的认证请求已经完成，用户信息已经被authState回调写入localStorage，此时读取本地用户值不再为空，流程即可正常执行，不需要重新输入账号密码。
• 额外的隐性触发点：服务构造函数的authState订阅里，无用户分支直接执行localStorage.setItem('user', null)，这个操作实际会把值转为字符串"null"存入本地，如果后续有代码没有用JSON.parse处理，会读取到字符串"null"而非空值，进一步放大时序问题的影响。

修复方案 #

• 补全所有本地用户值读取的空值防护逻辑，尤其是isEmailVerified计算属性，避免对null对象直接访问属性：

  get isEmailVerified(): boolean {
    // 读取时先兜底空值，JSON.parse解析失败时默认返回null
    const user = JSON.parse(localStorage.getItem('user') || 'null');
    // 先确认user存在，再访问emailVerified属性
    return user !== null && user.emailVerified === true;
  }
  
  get isLoggedIn(): boolean {
    const user = JSON.parse(localStorage.getItem('user') || 'null');
    return user !== null && user.emailVerified === true;
  }
  

• 调整登录流程的执行顺序，不要依赖异步更新的localStorage做即时权限判断：在SignIn方法返回的Promise resolve后，直接从Firebase返回的用户对象中读取emailVerified状态做权限判断，等状态确认后再触发路由跳转，避免因本地存储更新延迟导致的校验空值问题。
• 修正本地存储的无用户存值逻辑：无用户时不要把null直接作为值存入localStorage，直接调用localStorage.removeItem('user')清空对应键值，避免类型转换带来的隐性异常。
• 给路由权限守卫增加authState等待逻辑：在做受限区域跳转校验时，先等待Firebase首次authState推送完成，再读取用户状态做权限判断，避免应用初始化、登出后跳转阶段的空值报错。

内容的提问来源于stack exchange，提问作者Luiz Henrique Oliveira