不能在聚合管道里安全实现字段脱敏，因$substr+$concat存在弃用、UTF-8截取乱码、输入不稳导致错位、硬编码难测试、空值崩溃、跨节点结果不一致、错误掩码持久化、审计不可追溯等问题；应改用显式剔除敏感字段、视图控制可见性、掩码逻辑下推至应用层。
不能在聚合管道里安全实现字段脱敏，尤其是用 $substr、$concat 拼掩码这种做法——它既不安全，也不可靠，还容易出错。
为什么 $substr + $concat 不是脱敏
常见写法类似这样：
{ $project: { id_masked: { $concat: ["***-**-", { $substr: ["$id_number", -4, 4] }] } } }
问题不止一个：
-
$substr在 MongoDB 5.0 中已标记为弃用，实际调用的是$substrBytes，对中文、emoji 等 UTF-8 多字节字符按字节截取，极易产生乱码或崩溃 - 身份证号若含空格、短横线、长度不一（如旧版15位），
$substr会返回空或错位，比如"110101 19900307234X"被截成"234X"还是"7234"完全不可控 - 所有这类“掩码”都是硬编码逻辑，无法做单元测试，无法适配不同掩码策略（如手机号掩中间4位 vs 掩中间3位）
- 聚合阶段无运行时类型检查，字段为空、为 null、为数组时，
$substr直接返回null，前端可能报错或暴露原始值
副本集环境下聚合脱敏的真正风险点
在副本集里用聚合做脱敏，放大了两个隐藏问题：
- 主节点和从节点的 MongoDB 版本若不一致（比如 5.0.15 和 5.0.20），某些驱动或 shell 对
$substrBytes的行为兼容性不同，同一管道在不同节点执行结果可能不一致 - 如果管道中用了
$merge或$out写回集合，而脱敏逻辑有缺陷，可能把错误掩码（如"***-**-null"）持久化进数据库，污染数据源 - 审计日志里只记录聚合命令本身，不记录脱敏后值——你无法追溯某条“***-**-1234”到底对应哪个原始身份证号，违反 GDPR / 等保要求
该怎么做：明确分层与责任边界
在副本集上跑聚合，只做三件事：
- 用
$project显式剔除敏感字段：{ ssn: 0, phone: 0, id_number: 0 }，这是最干净、最可审计的“脱敏” - 用
$lookup+ 视图组合控制数据可见范围，比如创建一个user_public_view，定义里就根本不包含id_number字段 - 聚合只输出原始字段名（如
"id_number": "$id_number"），把掩码动作留给应用层——Node.js 用maskIdNumber()，Python 用redact_ssn()，统一走同一个函数，支持配置、测试、灰度
别让聚合管道承担它不该背的责任。字段变形不是数据库的事，是业务逻辑的事；而副本集的稳定性，恰恰依赖于每个组件职责清晰、行为确定。
