Flutter应用未登录启动时闪现红屏：Getter UID在null上被调用

核心原因 #

你此前认为getCurrentUser会优先跑完校验再执行后续逻辑的假设确实是错的：

• 标记为async、返回值是void的getCurrentUser方法，在没有被await的情况下被调用后，会立刻挂起让出执行权，Dart不会等待方法内部的登录校验、页面跳转逻辑跑完，就会继续执行main.dart里后续的、默认用户已登录的数据库查询代码。
• 等异步方法真正拿到auth校验结果、执行跳转逻辑的时候，后续代码已经提前触发了对null值的.uid属性访问，直接抛出“Getter 'UID' is null”的红屏错误；等红屏刚完成渲染，又被异步逻辑触发的Navigator跳转冲掉，就形成了“未登录用户启动时闪一下红屏、再进入登录页”的现象。
• 现有启动流程的逻辑顺序本身存在缺陷：默认所有进入应用的用户都是已登录状态，先跑需要uid的业务逻辑，再补判断要不要跳登录页，天然存在空指针风险。

可落地的修复方案 #

1. 从根源调整启动逻辑顺序（推荐方案） #

把原本“先跑业务逻辑、再校验登录状态跳页”的流程，改成“先等登录状态校验完成，再决定加载哪个页面，只在确认用户已登录的分支里跑依赖uid的业务逻辑”：

• 用FirebaseAuth.instance.authStateChanges()的流监听替代单次调用_auth.currentUser的校验方式，从根上避免状态不同步的问题。
• 替换MaterialApp原本的home页面逻辑，结构参考如下：

MaterialApp(
  home: StreamBuilder(
    stream: FirebaseAuth.instance.authStateChanges(),
    builder: (context, snapshot) {
      // 校验过程中先展示无业务逻辑的启动加载页，避免空值问题
      if (snapshot.connectionState == ConnectionState.waiting) {
        return const SplashLoadingPage();
      }
      // 未登录：直接渲染登录页，完全不会触达后续依赖uid的逻辑
      if (snapshot.data == null) {
        return const MyLoginScreen();
      }
      // 已登录但未验证邮箱：直接渲染邮箱验证页
      if (!snapshot.data!.emailVerified) {
        return const ValideMeScreen();
      }
      // 只有确认登录状态、邮箱验证通过后，才渲染主页面
      // 这里拿到的uid一定非空，再把uid传入主页面，执行后续数据库查询
      return MainHomePage(uid: snapshot.data!.uid);
    },
  ),
)

这种方式下，三个页面分支完全互斥，永远不会出现未登录用户跑到主页面逻辑里、触发null.uid访问的情况。

2. 小成本适配现有结构的修复方式 #

如果不想大改现有代码结构，可以针对性调整原getCurrentUser方法的执行逻辑：

• 把getCurrentUser的返回值从void改成Future<bool>，方法内部在不同分支返回对应的校验结果（未登录返回false、已验证返回true）。
• 把所有依赖uid的数据库查询代码，全部放到“确认用户已登录且邮箱验证通过”的代码分支里，绝对不要在分支判断外直接运行这些逻辑。
• 所有数据库查询的入口处加空值判断：如果取到的uid为null，直接中断查询流程，触发跳转登录页的逻辑，不要硬执行.doc(null)这类会直接抛错的操作。

3. 兜底优化 #

• 对于release模式下的红屏页面，替换成自定义的中性错误提示，避免极端边界情况下的刺眼报错影响用户体验。
• 该兜底方式只能掩盖表层报错，不能替代上面提到的逻辑顺序调整，根治问题还是要把校验逻辑放在所有业务逻辑之前。

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