mongodb视图无法实现字段掩码，仅支持过滤或重命名；真正掩码需在应用层处理或手动聚合构造，但性能差、难维护、不兼容所有驱动。
视图本身不能做字段掩码，只能过滤或重命名
MongoDB 视图（view）本质是带聚合管道的只读查询别名，它不支持对字段值做字符串替换、截断或加星号等掩码操作。你定义一个视图把 ssn 字段重命名为 ssn_masked，或者用 $project 把它设为 null，都不等于“脱敏”——只是隐藏或丢弃，原始值在底层集合里依然完整可查。
真正需要掩码（比如显示为 "***-**-1234"）必须在应用层处理，或借助聚合阶段如 $substrCP + $concat 手动构造，但这类操作无法复用、难维护，且不适用于所有驱动（例如 PHP 驱动对复杂字符串聚合的支持有限）。
- 视图适合做逻辑隔离：比如只暴露
{name: 1, email: 1}，屏蔽phone和address - 视图不适合做值变换：MongoDB 没有类似 SQL 的
REPLACE()或正则掩码函数 - 如果强行在视图里用聚合做掩码，每次查询都会触发实时计算，影响性能，且无法被索引加速
角色权限控制只能开关字段可见性，不能改字段内容
通过 createRole 定义的角色（如 readWithoutPii）可以限制用户对特定集合的字段访问，但这是粗粒度的“读/不读”，不是“读但变形”。即使你给角色配置了 "actions": ["find"] 并指定 "resource": {"collection": "users", "db": "app"}，MongoDB 也不会自动把 id_number 值替换成 "[REDACTED]"。
也就是说：db.createRole() 控制“能不能看到这个字段”，不控制“看到什么内容”。字段值是否脱敏，完全取决于查询时是否经过应用逻辑或聚合处理。
- 企业版支持字段级加密（FLE），但那是加密存储，不是运行时掩码，且要求客户端 SDK 支持解密
- 社区版无原生字段掩码能力，
$redact聚合阶段只能基于条件删整条文档，不能局部掩码 - 权限控制 + 视图组合使用，最多做到“某角色查视图 A，看不到敏感字段；查视图 B，能看到部分脱敏后字段”，但视图 B 仍需手动写掩码逻辑
可行的掩码方案：应用层统一处理 + 视图兜底
最稳定、可审计、兼容 MongoDB 5.0 社区版的做法，是把字段掩码逻辑收口到应用代码中，再用视图作为安全边界防止绕过。
以 Laravel + jenssegers/mongodb 为例：
class User extends Model
{
protected $casts = ['ssn' => 'string'];
// 序列化时自动掩码
public function getSSNAttribute($value)
{
return $this->isPreviewMode() ? substr($value, -4) : '[REDACTED]';
}
// toArray() 时排除原始字段，注入掩码后字段
public function toArray()
{
$arr = parent::toArray();
unset($arr['ssn']);
$arr['ssn_masked'] = $this->ssn;
return $arr;
}
}
同时创建一个只读视图，强制约束查询路径：
db.createView("users_safe", "users", [
{ $project: { _id: 1, name: 1, email: 1, created_at: 1 } }
])
- 所有前端接口必须走
users_safe视图查询基础字段 - 敏感字段（
ssn,phone）只允许通过模型方法访问，禁止直接取原始属性 - 数据库用户权限仅授予对视图的
find，禁止对底层集合users的直接读写
容易忽略的关键点：索引失效与审计盲区
一旦你在应用层做掩码，就彻底失去了数据库层面的字段语义。这意味着：
- 无法对掩码后字段建索引（
ssn_masked是 PHP 生成的，MongoDB 不知道它的存在） - 日志和慢查询分析里看不到实际脱敏逻辑，只有原始字段名，排查时容易误判
- 如果某个接口忘了调用模型访问器，直接
$user->ssn输出，就会泄露明文——这种漏洞极难通过静态扫描发现 - 视图不保存数据，也不参与事务，若业务需要“掩码后导出+校验”，必须确保导出逻辑也走同一套应用层掩码规则
真正要落地，得把掩码逻辑变成不可绕过的契约：要么封装进基类模型的 getAttribute，要么用中间件拦截所有响应并扫描关键词，而不是依赖开发自觉。
