Firestore两种安全规则写法的差异对比（含V1/V2版本）

你提到的两种Firestore安全规则写法，核心区别在于嵌套match和独立match的权限评估逻辑，下面分规则版本1（v1）和版本2（v2）分别说明：

规则版本1（v1）下的差异 #

在v1版本中，嵌套的match语句会继承并强制父级的权限规则：

• 第一种写法里，访问/cities/{city}/landmarks/{landmark}路径时，必须同时满足父级/cities/{city}的allow条件和子级/landmarks/{landmark}的allow条件，请求才会被允许。
• 第二种写法里，/cities/{city}/landmarks/{landmark}是独立的match规则，仅受自身allow条件约束，和/cities/{city}的规则没有关联。

举个实际例子：如果父级/cities/{city}的条件是request.auth != null（要求登录），子级landmarks的条件是true（允许所有访问），那么：

• 第一种写法：未登录用户访问landmarks会被拒绝（父级条件不满足）
• 第二种写法：未登录用户可以正常访问landmarks（仅检查自身条件）

规则版本2（v2）下的差异 #

v2版本默认启用递归匹配，权限评估逻辑改为：所有匹配到目标路径的规则都会被检查，只要有一条规则允许，请求就通过。两种写法的差异体现在路径匹配范围上：

• 第一种写法：match /cities/{city}会递归匹配该路径下的所有文档（包括landmarks子路径的文档），同时子级/landmarks/{landmark}也会匹配目标路径。访问landmarks时，只要父级或子级的allow条件有一个满足，请求就会被允许。
• 第二种写法：match /cities/{city}仅匹配cities下的直接文档（不包含landmarks子路径），match /cities/{city}/landmarks/{landmark}仅匹配该子路径的文档。访问landmarks时只会检查自身的规则，访问cities文档时仅检查对应规则。

同样用例子说明：如果父级/cities/{city}的allow read条件是true，子级landmarks的allow read条件是false，那么：

• 第一种写法：访问landmarks会被允许（父级规则匹配且允许）
• 第二种写法：访问landmarks会被拒绝（仅自身条件不满足）

两种写法的代码示例 #

第一种写法（嵌套match） #

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

        match /landmarks/{landmark} {
          allow read, write: if <condition>;
        }
    }
  }
}

第二种写法（独立match） #

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;
    }
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

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