Firestore规则v2递归通配符异常及规则重构适配咨询

一、非递归嵌套写法的正确性 #

你改写的非递归嵌套规则是正确的，它精准匹配了每一层的子集合（threads下的comments/likes、comments下的likes/子comments），确保不同层级的查询限制（threads列表限10、comments限5、likes限15）各自生效，解决了原递归通配符导致的规则冲突问题。但确实存在代码冗余的问题，相同的规则逻辑重复编写了多次。

二、优化重构方案 #

可以通过函数复用和精准通配符匹配来简化代码，减少冗余：

1. 封装重复规则为函数 #

将重复的allow get、allow write逻辑封装成通用函数，避免重复编写：

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    // 通用规则函数
    function allowSignedInRead(limit) {
      return isSignedIn() && (request.method == 'get' || (request.method == 'list' && isQueryLimitRespected(limit)));
    }

    match /threads/{userId}/userThreads/{threadId} {
      allow get, list: allowSignedInRead(10);
      allow write: false;

      match /comments/{commentId} {
        allow get, list: allowSignedInRead(5);
        allow write: false;

        match /likes/{likeId} {
          allow get, list: allowSignedInRead(15);
          allow write: false;
        }

        match /comments/{commentId} {
          allow get, list: allowSignedInRead(5);
          allow write: false;
        }
      }

      match /likes/{likeId} {
        allow get, list: allowSignedInRead(15);
        allow write: false;
      }
    }
  }
}

2. 用通配符匹配同类型子集合（替代嵌套重复） #

如果你的数据模型中，所有层级的comments和likes规则完全一致，可以用全局子集合匹配的方式，在顶层匹配所有符合路径模式的集合，避免嵌套重复：

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    function allowSignedInRead(limit) {
      return isSignedIn() && (request.method == 'get' || (request.method == 'list' && isQueryLimitRespected(limit)));
    }

    // 匹配threads下所有层级的userThreads
    match /threads/{userId}/userThreads/{threadId} {
      allow get, list: allowSignedInRead(10);
      allow write: false;
    }

    // 匹配所有层级的comments集合（包括userThreads下、comments下的子comments）
    match /threads/{userId}/userThreads/{threadId}/{path=**}/comments/{commentId} {
      allow get, list: allowSignedInRead(5);
      allow write: false;
    }

    // 匹配所有层级的likes集合（包括userThreads下、comments下的likes）
    match /threads/{userId}/userThreads/{threadId}/{path=**}/likes/{likeId} {
      allow get, list: allowSignedInRead(15);
      allow write: false;
    }
  }
}

这种写法既覆盖了所有层级的子集合，又避免了嵌套冗余，逻辑更清晰。

三、第三种递归通配符写法的行为一致性 #

你尝试的match /{path=**}/likes/{likeId}写法，在规则v2中是行为一致的：

• {path=**}会匹配零或多个路径段，因此该规则会覆盖userThreads/{threadId}/likes、userThreads/{threadId}/comments/{commentId}/likes、userThreads/{threadId}/comments/{commentId}/comments/{subCommentId}/likes等所有层级的likes集合；
• comments的规则同理，会覆盖所有层级的comments集合；
• 每个集合的get、list限制（likes限15、comments限5）和原非递归嵌套规则完全一致，对静态NoSQL模型的访问控制效果相同。

需要注意的是，这种写法要确保路径范围被限制在/threads/{userId}/userThreads/{threadId}下，避免意外匹配到其他无关路径，而你的规则已经将这些match嵌套在该路径下，因此是安全的。

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