如何基于Firestore安全实现投票/点赞计数增量？

1. 防止FieldValue.increment(1)被恶意篡改 #

要彻底杜绝客户端篡改增量值，核心是依赖Firebase安全规则做强制校验——客户端代码可被逆向篡改，不能作为唯一依据。

在安全规则中需做到：

• 仅允许已认证用户操作投票计数字段
• 强制校验计数的变化只能是+1或-1（对应点赞/取消点赞）
• 限制只能更新指定的计数字段

示例规则：

match /posts/{postId} {
  allow update: if request.auth != null &&
    request.resource.data.keys().hasOnly(["likesCount", "likedBy"]) &&
    (request.resource.data.likesCount == resource.data.likesCount + 1 ||
     request.resource.data.likesCount == resource.data.likesCount - 1);
}

无论客户端传什么增量参数，规则都会强制校验计数的变更范围，从根源上阻止恶意篡改。

2. 通过UserID列表验证重复投票的可靠性 #

这种方式是可靠的，但必须配合严格的安全规则约束，确保用户只能操作自己的ID，无法重复添加或篡改他人ID。

关键规则补充： #

match /posts/{postId} {
  allow update: if request.auth != null &&
    // 点赞逻辑：仅能添加当前用户ID，且原数组无该ID
    (request.resource.data.likedBy == resource.data.likedBy + [request.auth.uid] &&
     request.resource.data.likesCount == resource.data.likesCount + 1) ||
    // 取消点赞逻辑：仅能移除当前用户ID，且原数组存在该ID
    (request.resource.data.likedBy == resource.data.likedBy.remove(request.auth.uid) &&
     request.resource.data.likesCount == resource.data.likesCount - 1);
}

只要规则配置正确，用户无法重复投票，也无法替他人投票。但需注意：若帖子点赞量极大（十万级以上），likedBy数组会导致读取/校验性能下降，此时可改为反向存储——在用户文档下维护likedPosts数组，存储该用户点赞过的帖子ID，查询时直接检查用户文档，性能更优。

3. 基础点赞安全架构实现示例 #

数据结构（Firestore） #

每个帖子文档（posts/{postId}）包含：

• likesCount: 数字类型，存储点赞总数
• likedBy: 数组类型，存储点赞用户的uid

完整安全规则 #

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if true;
      allow update: if request.auth != null &&
        // 限制仅能更新指定字段
        request.resource.data.keys().hasOnly(["likesCount", "likedBy"]) &&
        // 原子校验点赞/取消点赞逻辑
        ((request.resource.data.likedBy == resource.data.likedBy + [request.auth.uid] &&
          request.resource.data.likesCount == resource.data.likesCount + 1) ||
         (request.resource.data.likedBy == resource.data.likedBy.remove(request.auth.uid) &&
          request.resource.data.likesCount == resource.data.likesCount - 1));
    }
  }
}

客户端代码（JavaScript） #

// 点赞操作
async function likePost(postId) {
  const user = firebase.auth().currentUser;
  if (!user) return;

  const postRef = firebase.firestore().collection('posts').doc(postId);
  await postRef.update({
    likesCount: firebase.firestore.FieldValue.increment(1),
    likedBy: firebase.firestore.FieldValue.arrayUnion(user.uid)
  });
}

// 取消点赞操作
async function unlikePost(postId) {
  const user = firebase.auth().currentUser;
  if (!user) return;

  const postRef = firebase.firestore().collection('posts').doc(postId);
  await postRef.update({
    likesCount: firebase.firestore.FieldValue.increment(-1),
    likedBy: firebase.firestore.FieldValue.arrayRemove(user.uid)
  });
}

用arrayUnion和arrayRemove确保用户ID不会重复添加/错误移除，结合安全规则的原子校验，实现完整的安全点赞流程。

关于Cloud Function处理单次点赞的实用性 #

不推荐用Cloud Function直接处理单次点赞操作，原因如下：

• 延迟问题：Cloud Function存在冷启动延迟（低调用量时更明显），会拖慢点赞操作的响应速度，影响用户体验
• 成本问题：单次调用成本虽低，但高并发点赞场景下，累积费用远高于客户端+安全规则的方案
• 冗余性：简单的点赞逻辑完全可以通过安全规则+客户端原子操作实现，无需额外的服务端计算

如果需要实现点赞后的异步业务逻辑（比如给作者发通知、增加积分等），可以用Cloud Function监听posts集合的更新事件，当likesCount变化时触发后续操作，这种场景下CF才具备实用性。

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