mongodb视图不能替代行级安全，因其为只读静态聚合管道，不支持动态会话变量、无法绑定当前用户身份，且用户可绕过视图直接查询底层集合；真正隔离需权限控制、应用层谓词与字段脱敏三者结合。
为什么 MongoDB 视图不能替代行级安全
MongoDB 视图是只读聚合管道的封装，本质是预定义的 $lookup、$match、$project 等阶段组合。它的过滤条件写死在视图定义里，无法动态绑定当前登录用户身份（比如 user_id: "$$CURRENT_USER" 这种语法不存在）。一旦创建，所有能读该视图的用户看到的是同一份结果。
- 视图定义中不能引用会话变量、认证上下文或客户端传入的参数
-
db.createView()的pipeline是静态 JSON 数组，不支持运行时变量插值 - 即使用户只能访问视图，只要他有
read权限，就能绕过视图直接查底层集合（除非显式撤回对该集合的权限）
真正可行的行级数据隔离路径
必须组合三层控制：权限隔离 + 应用层谓词 + （可选）字段级脱敏。没有哪一层能单独兜底。
- 给每个业务用户分配独立账号，并仅授予其对应集合的
read权限 —— 但注意：这仍是库/集合粒度，不是行粒度 - 在应用代码中，所有
find()、updateOne()等操作都强制拼接用户上下文谓词，例如：{ userId: "u123", status: { $ne: "deleted" } } - 避免把用户 ID 存在 URL 或前端可控字段中；从 JWT 或 session 中提取可信
userId，再拼入查询 - 如需复用逻辑，可封装 DAO 方法，禁止裸调用
collection.find({})
视图能帮上忙的有限场景
视图只适合做「静态数据裁剪」，比如屏蔽敏感字段、固定条件聚合，且前提是底层集合权限已严格限制。
- 示例：为客服角色创建视图，隐藏用户银行卡号字段：
db.createView("customer_public", "customers", [ { $project: { name: 1, email: 1, createdAt: 1, _id: 1 } } ]) - 必须同时执行：
db.grantRolesToUser("cs_agent", [{ role: "read", db: "myapp", collection: "customer_public" }])，并确保该用户对原始customers集合无任何权限 - 若忘记撤回对
customers集合的权限，视图形同虚设
容易被忽略的关键点
最危险的疏漏不是技术不会用，而是误信「开了 auth 就安全了」。MongoDB 的权限模型默认不阻止跨集合访问，也不校验查询内容合法性。
-
read角色允许执行任意find({})，包括全表扫描；它不校验你是否在find()里写了{ tenantId: "x" } - 没有类似 PostgreSQL 的
row_security_policies，服务端不会拦截或重写你的查询谓词 - 如果应用用了 ODM（如 Mongoose），务必检查中间件是否全局注入了 tenant 过滤；否则某个 controller 漏掉一行
.where({ tenantId: req.tenant.id })就全线崩溃
