Firebase中如何实现类Google Docs的文档共享数据架构？

方案对比与选型建议 #

方案1：全局docs集合+ACL权限校验 #

• 核心逻辑：将所有文档迁移至全局docs集合，文档元数据中维护ACL信息（如owner字段、isPublic布尔值、sharedUsers用户ID数组），通过安全规则校验权限。
• 优势：
  • 单一数据源，彻底避免数据同步问题，维护成本低
  • 权限逻辑集中管理，后续扩展协作、版本控制等功能更灵活
  • 查询逻辑清晰，用户可通过owner == auth.uid快速筛选自己的文档
• 注意事项：需要迁移现有用户集合下的文档，调整前端查询逻辑适配新结构。

方案2：用户集合复制文档+Cloud Functions同步 #

• 核心逻辑：在每个授权用户的集合下复制共享文档，通过云函数同步文档内容和权限变更。
• 劣势：
  • 数据冗余严重，存储成本翻倍
  • 同步逻辑极易出错（如云函数执行超时、重试失败），导致数据不一致
  • 权限管理分散，每个副本都需维护权限，后期迭代风险高
• 结论：不推荐，同步问题难以完全规避，长期维护成本极高。

方案3：保留用户集合路径+安全规则跨集合校验 #

• 核心逻辑：文档仍存储在所属用户的${userid}/docs/${docid}路径下，单独维护一个全局共享关系集合（如sharedPermissions），安全规则通过跨集合查询校验权限。
• 优势：无需迁移现有数据，前端查询逻辑基本不变
• 注意事项：跨集合查询会增加规则执行复杂度，且每次权限校验都会消耗数据库读取次数，需谨慎设计共享关系的存储结构。

最终推荐：优先选择方案1，单一数据源是最可靠的设计，短期的数据迁移成本远低于长期维护和扩展的隐性成本。若暂时无法迁移，方案3可作为过渡方案，但需严格控制跨集合查询的频率。

额外问题解答 #

Firebase Storage安全规则能否查询Firebase数据库元数据？ #

可以。Storage规则支持通过get()方法查询Firestore或Realtime Database中的数据，以此校验权限。

示例（Storage规则查询Firestore文档的ACL）：

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{userId}/docs/{docId}/{allPaths=**} {
      allow read: if 
        // 文档所有者直接访问
        request.auth.uid == userId ||
        // 校验文档是否公开
        get(/databases/(default)/documents/docs/{docId}).data.isPublic == true ||
        // 校验当前用户在共享列表中
        request.auth.uid in get(/databases/(default)/documents/docs/{docId}).data.sharedUsers;
    }
  }
}

注意：此类查询会消耗数据库读取次数，需避免高频无意义查询。

如何控制数据库访问成本？ #

• 优化安全规则：将常用权限标识（如isPublic）存入Storage自定义元数据，减少规则对数据库的依赖；避免在规则中进行嵌套查询或全表扫描。
• 前端查询优化：前端仅请求用户有权限的文档，比如通过owner == auth.uid筛选私有文档，通过预定义的共享文档列表查询授权内容，避免不必要的全集合查询。
• 缓存策略：对公开文档或高频访问的共享文档，在前端或Cloud Functions中缓存元数据，降低数据库读取频率。
• 索引优化：为所有查询字段创建复合索引，避免无索引查询导致的全表扫描（会额外消耗大量读取次数）。
• 成本监控：开启Firebase预算告警，实时监控数据库读取/写入次数，及时排查异常高消耗操作。

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