Firestore规则：如何管控公开/私有用户的帖子读取权限？

核心优化方案（解决批量更新与高读取成本问题） #

当前方案的核心痛点是将账号可见性冗余存储在每条帖子、评论中，既导致更新成本极高，又增加了规则验证的读取开销。优化思路是将账号可见性仅存储在用户文档中，帖子/评论仅保留ownerId字段，从根源解决问题。

优化后的安全规则

match /posts/{postId} {
  allow read: isValid(resource.data.ownerId);

  match /comments/{commentId} {
    allow read: isValid(resource.data.ownerId);
  }
}

function isValid(ownerId) {
  // 读取用户文档获取账号可见性
  let ownerProfile = get(/databases/$(database)/documents/users/$(ownerId));
  let isPublicAccount = ownerProfile.data().account_visibility == "public";
  // 两种授权情况：公开账号，或当前用户已关注该私有账号
  return isPublicAccount || exists(/databases/$(database)/documents/users/$(ownerId)/followers/$(request.auth.uid));
}

优化效果说明

1. 彻底解决批量更新问题：用户修改账号可见性时，仅需更新自身的/users/{id}文档，无需处理任何帖子或评论，完全消除了数千条文档批量更新的成本和复杂度。
2. 大幅降低规则读取成本：Firestore规则会对同一请求中重复读取的文档进行缓存。例如，当信息流中有同一作者的10条内容时，get(/users/{ownerId})只会执行1次读取，而非每条内容都重复读取，滚动信息流时的读取量会显著下降。

额外优化建议

• 客户端查询拆分：客户端可并行发起两个查询：
  • 查询所有公开用户的帖子（可通过维护公开用户列表或结合用户文档的集合组查询实现）
  • 查询自己关注的用户的所有帖子
    合并结果后展示，减少规则层面需要过滤的内容数量，进一步降低读取开销。
• 反向存储关注关系：在/users/{uid}/following/{targetUid}中存储用户的关注列表，客户端可直接获取关注的用户ID列表，用于构建第二个查询的过滤条件，减少规则中exists查询的执行次数。

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