mongodb视图创建必须避开$out和$merge阶段，因其仅定义只读查询逻辑；需用$project等脱敏，且须显式授权用户对视图所在数据库的read权限，视图定义公开、不可索引，性能依赖源集合索引。
db.createView() 创建视图时必须避开 $out 和 $merge
直接在视图定义里写 $out 或 $merge 会报错：MongoServerError: Views cannot contain $out or $merge stages。这不是语法错误，而是 MongoDB 强制的架构限制——标准视图只负责“定义查询逻辑”，不落地存储，所以禁止任何写入类阶段。
常见踩坑点：
- 在
$lookup的子管道里嵌套用了$merge，同样被拒绝 - 误把物化视图（需 Atlas 专用功能）的写法套用到本地部署的
db.createView() - 试图用视图替代 ETL 流程，结果卡在 pipeline 阶段校验上
正确做法是：脱敏逻辑全用 $project、$redact、$unset 或 $cond 实现。例如隐藏手机号后 4 位：{ $substrCP: ["$phone", 0, -4] } 配合 $concat 拼成 "138****1234"。
只读视图本身不解决权限问题，必须额外授权用户
视图只是逻辑层抽象，db.createView("safe_users", "users", [ ... ]) 创建完后，普通用户连 db.safe_users.find() 都会被拒绝，除非显式授予对视图所在数据库的 read 权限。
关键细节：
- 用户必须在视图所在的数据库（比如
testdb）中创建，或通过admin库用readAnyDatabase（不推荐） - 不能只给源集合（
users）授权，而忽略视图名（safe_users）——MongoDB 把视图当作独立命名对象校验权限 - 如果视图 pipeline 里用了
$lookup关联其他库的集合，那些库也得单独授权，否则查视图时在$lookup阶段就报not authorized
典型授权命令：db.createUser({ user: "reporter", pwd: "x", roles: [{ role: "read", db: "testdb" }] }) —— 这样 reporter 才能查 testdb.safe_users。
敏感字段不能硬编码进视图 pipeline
视图定义是公开的：db.getCollectionInfos({ name: "safe_users" }) 返回结果里直接包含原始 pipeline，包括所有字段名、条件、甚至硬写的过滤值。如果 pipeline 里写了 { $match: { status: "active", dept: "finance" } }，任意有 listCollections 权限的人都能看到 “finance” 这个部门名。
更危险的是脱敏逻辑本身暴露业务规则，比如：{ $cond: { if: { $eq: ["$level", "vip"] }, then: "$email", else: "<hidden>" } }</hidden> 会泄露 VIP 判定字段和策略。
应对方式：
- 避免在 pipeline 中出现真实业务关键词（如部门名、角色名、状态码），改用泛化占位符（
"dept_code": 101） - 敏感字段映射关系不要写死，改由应用层控制展示逻辑
- 定期用
db.runCommand({ listCollections: 1, filter: { type: "view" } })检查视图定义是否意外泄露信息
视图性能依赖底层集合索引，且无法加索引
你不能对视图执行 db.safe_users.createIndex()，MongoDB 会返回 not supported on views。视图查询性能完全取决于源集合是否建了匹配 pipeline 过滤/排序条件的索引。
例如视图 pipeline 是：[ { $match: { status: "active" } }, { $sort: { created_at: -1 } } ]，那么源集合 users 上最好有复合索引：{ status: 1, created_at: -1 }。
容易忽略的点：
-
$lookup关联的集合，其被关联字段（如orders.user_id）也必须有索引，否则整个视图查询变慢 - 视图用了
$facet，每个子管道的筛选字段都应有对应索引 - 使用
explain("executionStats")查视图时，看到的executionStages是展开后的实际执行计划，可据此反推缺哪些索引
真正要优化视图性能，只能回到源集合调优，而不是在视图上做文章。
