Firestore 安全规则不会自动过滤数据，而是验证查询是否必然只访问被授权的文档；若查询未包含与规则中 resource.data 字段（如 company_id）相匹配的条件，即使文档实际存在，也会因规则无法验证而拒绝访问。
firebase 安全规则不会自动过滤数据，而是验证查询是否**必然**只访问被授权的文档；若查询未包含与规则中 `resource.data` 字段（如 `company_id`）相匹配的条件，即使文档实际存在，也会因规则无法验证而拒绝访问。
在你的场景中，members 是 branch 文档下的子集合，且规则依赖 resource.data.company_id 进行权限校验：
match /{path=**}/members/{member} {
function isCompanyAdmin(companyId, userId) {
return companyId != null; // 试图读取 resource.data.company_id
}
allow read: if request.auth != null && isCompanyAdmin(resource.data.company_id, request.auth.uid);
}⚠️ 关键问题在于：Firestore 规则中的 resource.data 仅在单文档操作（如 get()、update()）时可用；而在集合查询（如 getDocs()）中，规则引擎无法预知每个匹配文档的 company_id 值，因此 resource.data.company_id 为 null，导致 isCompanyAdmin() 返回 false，最终触发 Missing or insufficient permissions 错误。
✅ 正确做法是：让客户端查询显式声明其“有权访问的范围”——即通过 where() 或 orderBy() 将 company_id 作为查询约束条件，使规则引擎能静态验证该查询结果必然满足权限逻辑。
✅ 修改后的安全规则（推荐）
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// 显式匹配路径：/branch/{branchId}/members/{member}
match /branch/{branchId}/members/{member} {
allow read: if request.auth != null
&& resource.data.company_id == get(/databases/$(database)/documents/branch/$(branchId)).data.company_id
&& isCompanyAdmin(resource.data.company_id, request.auth.uid);
function isCompanyAdmin(companyId, userId) {
// 示例：检查用户是否在 company_admins 集合中（需根据实际模型调整）
return get(/databases/$(database)/documents/companies/$(companyId)/admins/$(userId)).data.exists == true;
}
}
}
}✅ 客户端查询必须携带 company_id 约束
假设每个 member 文档都存储了 company_id 字段（如 { name: "Alice", company_id: "cmp_123" }），则查询必须包含 where("company_id", "==", ...)：
import { doc, collection, query, where, getDocs } from "firebase/firestore";
// ✅ 正确：查询明确限定 company_id（服务端可验证）
const branchRef = doc(db, "branch", branch_id);
const membersRef = collection(branchRef, "members");
const q = query(membersRef, where("company_id", "==", "cmp_123")); // ← 必须添加！
const snapshot = await getDocs(q);
snapshot.forEach((doc) => {
console.log(doc.id, "=>", doc.data());
});? 为什么 orderBy("company_id") 有时也有效？
当规则中使用 resource.data.company_id 且未配合 where() 时，orderBy("company_id") 可作为“隐式约束”帮助规则引擎推断查询范围（尤其配合 limit()），但这不是可靠方案。官方明确要求：所有查询必须包含足以满足规则条件的 where() 子句。依赖 orderBy() 属于未定义行为，易在规则升级或数据分布变化后失效。
? 注意事项总结
- ❌ 不要依赖 resource.data 在无约束查询中生效；
- ✅ 每个读取子集合的查询，必须包含与规则中 resource.data.xxx 字段严格匹配的 where() 条件；
- ✅ 若 company_id 由父文档 branch 决定，建议在写入 member 时冗余存储该字段（Denormalization），确保规则可验证；
- ✅ 使用 Rules Playground 测试时，务必选择 “Query” 模式 并输入完整查询条件（含 where），而非仅测试单文档 get()；
- ? 权限逻辑应尽量基于 request.auth.token 自定义声明（如 request.auth.token.company_id）或独立权限集合（如 /companies/{cid}/admins/{uid}），避免过度依赖子文档字段。
遵循以上原则，即可彻底解决 Missing or insufficient permissions 问题，同时保障数据访问的安全性与可扩展性。
