如何设计支持群组专属写入、全局可读的Firestore Schema？

你提出的「全服务用户可读取所有文档、仅群组成员可编辑所属群组文档」的需求，完全可以通过Firestore原生安全规则实现，是该场景下的行业标准方案，无需依赖全局自定义角色或触发器同步逻辑。

方案1：中小规模群组（单群成员<10000人） #

这是最常用的轻量化实现，核心思路是将成员列表直接存放在群组文档的数组字段中：

Schema设计 #

• 群组集合路径：groups/{groupId}
  每个群组文档包含members字段，类型为字符串数组，存储所有群成员的用户UID
• 业务文档集合路径（例如群动态、群文件等）：{businessCollection}/{docId}
  每个业务文档包含groupId字段，关联该文档所属的群组ID

安全规则配置 #

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 所有业务文档的公共读权限
    match /{businessCollection}/{docId} {
      allow read: if request.auth != null;
      // 写权限校验：当前用户属于文档关联的群组成员
      allow create, update, delete: if request.auth != null 
        && request.auth.uid in get(/databases/$(database)/documents/groups/$(request.resource.data.groupId)).data.members;
    }
    // 群组本身的读写规则可按需补充，不影响上述业务逻辑
    match /groups/{groupId} {
      allow read: if request.auth != null;
    }
  }
}

注：安全规则内的get请求会自动缓存，同一次请求内多次调用相同路径的get只会产生1次文档读取费用，无需担心成本问题

方案2：大规模群组（单群成员≥10000人） #

如果群组人数较多，避免单文档数组字段过大带来的性能和容量限制，可以将成员列表拆分为子集合存储：

Schema设计 #

• 群组集合路径：groups/{groupId}
• 群成员子集合路径：groups/{groupId}/members/{uid}
  每个成员文档的ID直接对应用户UID，无需额外字段，仅需存在即表示是群成员
• 业务文档设计同方案1

安全规则配置 #

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{businessCollection}/{docId} {
      allow read: if request.auth != null;
      // 写权限校验：对应群组的members子集合下存在当前用户的UID文档
      allow create, update, delete: if request.auth != null 
        && exists(/databases/$(database)/documents/groups/$(request.resource.data.groupId)/members/$(request.auth.uid));
    }
  }
}

原有方案问题说明 #

• 全局角色-based访问控制本身是为平台级权限设计的，确实不适合动态多群组的场景，无需采用
• 触发器同步复制文档的方案完全可以被上述原生安全规则替代，不存在循环调用、稳定性差的问题

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