如何在Firestore中检查用户UID存在，避免ReferralId被覆盖丢失积分？

当然可以！你的思路完全正确——在生成新推荐ID并覆盖用户数据前，先检查目标用户是否已经存在且拥有有效的推荐ID，就能从根源上避免积分丢失的问题。咱们来调整你的代码实现这个逻辑：

核心思路 #

先查询用户的现有详情记录，判断两个关键条件：

1. 用户的uid对应的记录是否存在
2. 该记录中是否已经有非空/符合业务规则的referralId

如果两个条件都满足，就跳过后续的更新操作；如果任一条件不满足（比如用户是新用户，或者原有推荐ID无效），再执行生成新ID、更新数据的逻辑。

修改后的代码示例 #

假设你使用的是异步查询数据库的方式（比如Firebase Firestore/Realtime Database），我们可以把processUser改成异步方法来实现检查：

async processUser(result, firstName, lastName) {
  // 第一步：查询用户现有详情数据
  const existingUserDetail = await this.getUserDetailData(result.user.uid);

  // 第二步：判断是否已有有效推荐ID
  // 这里的判断逻辑可以根据你的业务需求调整，比如检查referralId长度是否为8位
  const hasValidReferralId = existingUserDetail 
    && existingUserDetail.referralId 
    && existingUserDetail.referralId.length === 8;

  if (hasValidReferralId) {
    console.log(`用户 ${result.user.uid} 已有有效推荐ID，跳过更新操作`);
    return; // 直接返回，不执行后续覆盖逻辑
  }

  // 第三步：如果没有有效ID，执行原有的数据更新逻辑
  const referralId = this.utilService.generateRandomString(8);
  this.setUserData(result.user);
  this.setUserDetailData(result.user.uid, firstName, lastName, referralId);
  this.referralService.addUserToWaitlist(referralId);
}

关键细节说明 #

• 异步处理：用async/await确保我们先拿到数据库查询结果，再做判断，避免出现“先更新再查询”的时序问题
• 灵活的判断条件：你可以根据自己的表结构和业务规则调整hasValidReferralId的判断逻辑，比如检查referralId是否未过期、是否符合特定格式等
• 日志排查：添加日志方便后续排查问题，清楚知道哪些用户的操作被跳过
• 并发安全（可选）：如果你的系统存在高并发场景（比如同一用户同时触发多次该方法），可以考虑使用数据库的原子操作或事务，进一步防止意外覆盖

适配你的表结构 #

请确保getUserDetailData方法能正确根据uid查询到用户的详情记录——如果你的表结构中存储用户推荐ID的字段名不是referralId，或者查询方式不同，记得对应修改代码中的字段和查询逻辑。

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