如何在 Cloud Firestore 中防止重复数据录入-js教程-PHP中文网

本文详解在无原生主键机制的 Firestore 中，通过文档 ID 策略与前置查重两种可靠方式，确保 regNo 等业务唯一字段不重复，并提供可直接落地的 React + Firebase 实战代码与关键注意事项。

本文详解在无原生主键机制的 firestore 中，通过文档 id 策略与前置查重两种可靠方式，确保 `regno` 等业务唯一字段不重复，并提供可直接落地的 react + firebase 实战代码与关键注意事项。

Cloud Firestore 作为无模式、分布式 NoSQL 数据库，不支持传统关系型数据库中的主键约束（PRIMARY KEY）或唯一索引（UNIQUE INDEX）。这意味着你无法像在 MySQL 或 PostgreSQL 中那样，仅靠数据库层自动拒绝重复的 regNo 值。但正因如此，开发者需主动设计防重逻辑——核心思路有两种：利用文档 ID 的天然唯一性实现“以业务字段为 ID”，或在写入前显式查询校验。二者各有适用场景，下文将结合你的实际代码逐一展开。

✅ 方案一：将 regNo 作为文档 ID（推荐，高效且原子）

Firestore 每个文档的 ID 在集合内绝对唯一，且写入操作（setDoc）具有原子性。若你确认 regNo 具备全局业务唯一性（如医院挂号号、学号），最简洁、高性能的做法是直接用 regNo 作为文档 ID，而非存为普通字段：

const handleAdd = async (e: React.FormEvent) => {
  e.preventDefault();

  // ✅ 关键校验：regNo 不能为空或无效值
  if (!userInfo.regNo?.trim()) {
    toast.error("注册号（regNo）不能为空");
    return;
  }

  try {
    const docRef = doc(db, "mrisystems", userInfo.regNo); // ← regNo 作为文档 ID

    // 使用 setDoc 并设置 { merge: false }（默认行为），若文档已存在则抛出错误
    await setDoc(docRef, {
      ...userInfo,
      timeStamp: serverTimestamp(),
    });

    toast.success("用户信息保存成功");
  } catch (error) {
    console.error("写入失败:", error);
    // Firestore 会返回特定错误码，可精准判断是否为“文档已存在”
    if (error.code === 'permission-denied') {
      toast.error("权限不足，请检查安全规则");
    } else {
      toast.error("注册号已存在，请勿重复提交");
    }
  } finally {
    navigate("/users");
  }
};

⚠️ 重要前提：你需要在 Firestore 安全规则中明确允许基于 regNo 的写入控制（例如限制用户只能创建/修改自己 regNo 对应的文档），否则存在被恶意覆盖的风险。

✅ 方案二：前置查询校验（灵活但需注意竞态）

当 regNo 不能直接用作文档 ID（如需保留系统生成 ID、或 regNo 需与其他字段组合唯一），则必须在 addDoc 前执行一次查询：

const handleAdd = async (e: React.FormEvent) => {
  e.preventDefault();

  if (!userInfo.regNo?.trim()) {
    toast.error("注册号（regNo）不能为空");
    return;
  }

  try {
    // ? 查询是否存在相同 regNo 的文档
    const q = query(
      collection(db, "mrisystems"),
      where("regNo", "==", userInfo.regNo)
    );
    const querySnapshot = await getDocs(q);

    if (!querySnapshot.empty) {
      toast.error("该注册号已存在，请检查后重新输入");
      return;
    }

    // ✅ 查询通过，执行新增
    await addDoc(collection(db, "mrisystems"), {
      ...userInfo,
      timeStamp: serverTimestamp(),
    });

    toast.success("用户信息添加成功");
  } catch (error) {
    console.error("查询或写入失败:", error);
    toast.error("操作失败，请稍后重试");
  } finally {
    navigate("/users");
  }
};

⚠️ 注意竞态条件（Race Condition）：此方案在高并发场景下存在微小窗口期（A 查询→B 查询→A 写入→B 写入），导致两个请求同时通过校验并写入重复数据。如对一致性要求极高，强烈建议优先采用方案一（ID 策略）；若必须用方案二，可结合事务（runTransaction）进一步加固，但 Firestore 事务不支持跨文档查询，因此仍需配合服务端函数（如 Cloud Functions）做最终幂等校验。

? 关键总结与最佳实践

首选策略：将业务唯一标识（如 regNo）设为文档 ID，利用 Firestore 底层保证唯一性，性能最优、代码最简；
避免误区：不要依赖 isEmpty(id) 判断新增/更新逻辑来防重——id 来自 URL 参数，与 regNo 是否重复无任何关系；
表单验证前置：在 handleInput 或提交时同步校验 regNo 格式与非空，提升用户体验；
安全规则同步更新：若使用 regNo 为 ID，务必在 Firestore Security Rules 中加入类似 request.resource.data.regNo == request.auth.token.regNo 的校验，防止越权写入；
错误处理专业化：捕获 FirebaseError 并根据 error.code（如 not-found, permission-denied）给出精准提示，而非统一 toast.error("User Already Exists")。

通过以上任一方案，你即可在 Firestore 中稳健实现 regNo 唯一性保障。记住：NoSQL 的灵活性要求开发者更主动地承担数据完整性责任——而这正是构建可靠应用的关键一步。