Firestore安全规则中通用write规则是否会覆盖细粒度写规则

首先给出明确结论：在同一路径的集合文档规则下，新增通用allow write规则不会覆盖已经定义的create、update、delete三类细粒度写操作规则。

核心判定规则说明 #

Firestore安全规则的权限校验逻辑不存在“通用规则覆盖细粒度规则”的设计，所有匹配当前请求路径的规则会按照逻辑或的关系做运算：只要任意一条规则的校验条件为真，当前操作就会被允许；只有所有匹配路径的规则校验条件全部为假时，操作才会被拦截。

• 通用allow write本质是语法糖，等价于同时声明对create、update、delete三类写操作的权限要求，本身没有更高的判定优先级。
• 新增通用写规则的实际效果，是为所有三类写操作额外增加了一个独立的放行通道，而非替换原有细粒度规则的校验逻辑。

实际生效示例 #

举个同路径下的规则配置场景：

match /cities/{cityId} {
  // 细粒度规则：仅已登录用户可创建城市文档
  allow create: if request.auth != null;
  // 细粒度规则：仅文档归属者可更新文档
  allow update: if request.auth.uid == resource.data.ownerUid;
  // 细粒度规则：仅管理员可删除文档
  allow delete: if request.auth.token.admin == true;
  // 新增的通用写规则：所有已登录用户可执行写操作
  allow write: if request.auth != null;
}

这套配置的实际权限效果是：

1. 创建操作：两条放行条件（已登录的create规则、已登录的write规则）完全等价，和单独定义细粒度create规则的效果一致
2. 更新操作：原本要求的“仅归属者可更新”的限制被削弱，任意已登录用户都可更新任意城市文档——因为只要满足write规则的已登录条件，就会被直接放行，不会再校验update规则要求的归属者权限
3. 删除操作：原本要求的“仅管理员可删除”的限制被削弱，任意已登录用户都可删除任意城市文档

常见踩坑提醒：不少开发者第一次写规则时，会误以为规则是从上到下顺序匹配、命中第一条就不再往下校验，这种理解完全不符合Firestore安全规则的设计逻辑。如果不加思考新增了条件更宽松的通用写规则，原本精心设计的细粒度权限控制会直接失效，很多线上权限漏洞都是因为这个逻辑认知偏差导致的。

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