Firebase获取用户时addOnCompleteListener被跳过致应用崩溃

核心问题根因 #

你遇到的异常并非数据库读取的监听器被跳过，本质是将异步执行的网络读取逻辑，按同步阻塞逻辑的方式使用：

• databaseReference.get()发起的实时数据库请求是异步后台执行的，主线程不会等待网络请求返回结果，绑定完监听器后代码会立刻走到return user的逻辑
• 此时异步请求还在网络交互阶段，单例的user字段尚未被赋值，方法直接返回null
• 后续拿null对象拼接Toast字符串时会触发空指针崩溃，整个登录流程被中断，你自然感知不到后续数据库请求完成、监听器触发的过程——不是监听器不运行，是程序还没等它运行就已经崩了

你可以对照现有代码的实际执行顺序验证：

1. 登录成功触发完成回调
2. 调用getUser()，检测到user为null，发起异步数据库请求并绑定完成监听器
3. 不等请求返回，直接执行return null
4. 拿返回的null值拼接Toast文本，触发空指针崩溃
5. 数毫秒后数据库请求返回结果，触发监听器想给user赋值时，页面已经因为崩溃退到后台，你完全感知不到这个过程

至于你说其他场景用同样代码能正常运行，本质是那些场景下没有把getUser()的返回值当成同步结果使用，后续逻辑都是写在数据库读取的回调里执行的。

具体修复方案 #

不要依赖方法的同步返回值获取用户对象，把所有依赖用户数据的后续逻辑，挪到数据库读取完成的回调里执行：

• 给getUser()方法增加回调接口，等用户数据真正加载完成、赋值给单例缓存后，再通过回调通知调用方执行后续逻辑
• 把Toast展示、跳转首页这类和用户数据强绑定的逻辑，从同步路径挪到回调内执行

改造步骤 #

1. 定义通用的用户加载完成回调接口：

public interface OnUserLoadedListener {
    void onUserLoaded(User user);
}

2. 改造单例类的getUser()方法，去掉直接返回值的写法：

public void getUser(OnUserLoadedListener listener) {
    // 已有缓存的用户数据，直接回调返回
    if (user != null) {
        listener.onUserLoaded(user);
        return;
    }
    FirebaseAuth mAuth = FirebaseAuth.getInstance();
    String userID = mAuth.getCurrentUser().getUid();
    DatabaseReference databaseReference = FirebaseDatabase.getInstance().getReference("Users").child(userID);
    databaseReference.get().addOnCompleteListener(task -> {
        if (!task.isSuccessful()) {
            Log.e("firebase", "Error getting data", task.getException());
            // 加载失败也要触发回调，避免页面状态卡死
            listener.onUserLoaded(null);
            return;
        }
        User currUser = task.getResult().getValue(User.class);
        user = currUser;
        // 数据缓存完成后，触发回调执行后续逻辑
        listener.onUserLoaded(user);
    });
}

3. 改造登录成功后的调用逻辑，把和用户数据相关的操作全部放到回调内：

if (task.isSuccessful()) {
    LoggedInUser loggedInUser = LoggedInUser.getInstance();
    loggedInUser.getUser(loadedUser -> {
        // 加载失败的场景做兜底处理
        if (loadedUser == null) {
            Toast.makeText(LoginActivity.this, "用户信息加载失败，请重试", Toast.LENGTH_LONG).show();
            return;
        }
        Toast.makeText(LoginActivity.this, 
            getString(R.string.welcome_back) + loadedUser.name, 
            Toast.LENGTH_LONG).show();
        // 跳转主页等后续业务逻辑也放在这里执行
    });
}

附加排查提示 #

• 可以在数据库读取的回调开头添加日志，验证监听器的实际触发情况：很多时候你以为监听器没触发，其实是程序崩溃打断了执行流程，打日志后就能看到回调是正常运行的
• 改造完成后如果出现读取权限报错，检查实时数据库的安全规则，确认已登录用户可以读取自己UID对应的节点数据
• 注意内存泄漏问题：Activity销毁时如果数据库请求还未返回，要及时移除对应的监听器，避免页面无法被回收

内容的提问来源于stack exchange，提问作者FΣynman