敏感字段不该单独建集合，除非生命周期与主体完全隔离；优先用应用层字段过滤和查询投影；MongoDB无字段级权限，须靠应用层投影和清洗控制访问。
敏感字段该不该单独建集合？
大多数情况——不该。拆成独立集合会把简单问题复杂化，尤其是当敏感字段和主业务数据强关联时（比如用户身份证号和 user_id）。你得频繁做 $lookup，查一次要两轮 IO，聚合管道变长，索引也难覆盖全路径。更麻烦的是事务里跨集合更新敏感字段，MongoDB 的分布式事务开销明显，出错回滚逻辑也更难兜住。
常见错误现象：find() 返回空对象，但 db.sensitiveData.findOne({ user_id: "xxx" }) 能查到——其实是应用层忘了拼接查询，或缓存没同步。
- 只在敏感字段生命周期/访问权限与主体完全隔离时才考虑独立集合（例如：审计日志里的脱敏操作记录，和用户资料本身无关）
- 如果只是“部分人不能看”，优先用应用层字段过滤 + 查询投影（
{ projection: { ssn: 0 } }），而不是物理隔离 - 独立集合必须和主集合共用分片键，否则跨分片
$lookup会被禁止
MongoDB 4.2+ 字段级加密（FLE）怎么配才不翻车？
FLE 不是开关一开就完事。它依赖客户端驱动的加密能力，服务端（mongod）根本不碰明文，所以密钥管理、Schema 定义、驱动版本三者必须咬死对齐，漏一个就 Failed to decrypt field 或直接报 Invalid key。
使用场景：合规强要求（如 HIPAA、GDPR）、字段值低频更新但高频读（如护照号）、且能接受客户端侧加解密带来的微小延迟。
- 密钥必须用
kmip或本地localMasterKey，别手动生成base64字符串塞进去——驱动会校验格式，错一位就整个集合写不进去 -
encrypt()的algorithm参数只能是"AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic"或"AEAD_AES_256_CBC_HMAC_SHA_512-Random"，拼错会静默失败 - 开启 FLE 后，所有对该集合的写操作必须走带加密配置的驱动连接；普通连接写进去的数据无法被加密查询命中
应用层手动加密 + 存字符串，要注意什么？
这是最常用也最容易出问题的方案。不是不能用，而是容易在“加密”和“存储”两个环节松懈：用 md5 或 sha256 当加密（它们不可逆，但也不防重放）、密钥硬编码在代码里、IV 每次都写死。
性能影响不大，但兼容性差——换语言重写服务时，AES-CBC 的填充方式、编码格式稍有差异，旧数据就再也解不开。
- 必须用
AES-256-GCM或至少AES-256-CBC+ 随机IV，且IV和密文一起存（比如拼成base64(IV) + ":" + base64(ciphertext)） - 密钥绝不能出现在代码或 config 文件里，走 KMS（如 AWS KMS、HashiCorp Vault）或环境变量注入
- 字段类型统一用
String，别存BinData——某些 ODM（如 Mongoose）对二进制字段的序列化行为不一致
为什么不能靠 MongoDB 角色权限挡住敏感字段？
因为字段级权限在 MongoDB 里根本不存在。read 角色要么能看到整条文档，要么看不到。你给某个用户分配 read 权限后，他执行 db.users.find({}, { name: 1, email: 1 })，只要没显式排除 ssn，而你又没在应用层做投影控制，他就可能通过 find({}, { ssn: 1 }) 直接捞走。
真实错误现象：安全扫描报告说“未授权访问敏感字段”，结果发现是 DBA 给开发账号开了 readAnyDatabase，而应用代码里压根没做字段白名单校验。
- 数据库权限只做最后一道防线，不是字段级访问控制的解决方案
- 真正可控的点只有两个：应用层查询投影（
projection） + 写入前字段清洗（比如收到ssn就立刻加密再存） - 如果必须用角色隔离，只能按集合切分——比如
users_public和users_sensitive，但这就回到第一个副标题的问题了
字段加密不是加个函数调用就完事，密钥轮换、旧数据迁移、驱动兼容性、查询语义变化——每个点都卡在业务能不能停、敢不敢动。最常被忽略的是：加密后的字段基本没法建高效索引，find({ encrypted_ssn: /abc/ }) 这种正则查询会直接失效。
