Firestore使用文档路径时权限被拒及异常UID问题排查

1. 集合组查询的规则匹配坑 #

你用集合组查询Notifications的时候，Firestore会扫描所有叫这个名字的集合。之前的通配规则match /{document = **}能覆盖所有路径，所以只要用户登录就能通过校验；但换成/UserGroups/{userGroup}/Notifications/{notification}这种具体路径规则后，要么是规则没覆盖全（哪怕你只有这一处Notifications集合，规则写法也得适配集合组查询的逻辑），要么是规则里没加文档级的权限校验——毕竟你的查询是找users数组包含当前用户UID的文档，规则得和这个业务逻辑对应上。

2. 修正规则写法 #

把规则改成下面这样，既能适配集合组查询，又能保证只有符合条件的用户能读取文档：

match /{path=**}/Notifications/{notification} {
  allow read: if request.auth != null && request.auth.uid in resource.data.users;
  allow write: if request.auth != null; // 写入权限可按需调整
}

• {path=**}通配任意父级路径，确保所有Notifications集合都能被这个规则覆盖
• request.auth.uid in resource.data.users和你的查询条件whereArrayContains("users", it)对应，让权限逻辑和业务逻辑完全对齐

3. 日志里陌生UID的原因 #

那个不存在的UID是Firestore规则引擎在预验证查询时用的测试值——Firestore会模拟几种场景来检查规则能否正确放行合法请求、拦截非法请求，这属于正常的规则评估流程，不是你发起的额外查询，不用在意。

4. 额外检查点 #

• 确认发起查询时用户已完成登录，auth.currentUser不为null（虽然你用了let，但如果登录状态还没同步完成就发起查询，UID会是null）
• 检查所有Notifications文档的users字段确实是数组类型，且里面的UID和用户实际UID一致
• 要是仍有问题，可在Firebase控制台的规则模拟器中测试集合组查询，能看到规则一步步的评估过程，方便定位问题

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