MongoDB 6.0中无法对CSFLE加密字段执行$set原地更新，因驱动仅拦截insertOne、replaceOne及全文档替换的findOneAndUpdate，$set被当作普通字段操作直接写入明文，导致解密失败且无警告。
MongoDB 6.0 中无法对已加密字段执行“原地更新”（in-place update），所有写入都必须走完整加解密流程；直接用 $set 修改加密字段值会写入明文，且无任何警告。
为什么不能用 updateOne({ _id }, { $set: { ssn: "new" } }) 更新加密字段
CSFLE 的自动加密只在驱动层拦截 insertOne、replaceOne 和 findOneAndUpdate（仅限全文档替换模式）等操作。而 $set 这类字段级更新操作不会触发加密逻辑——驱动认为你只是在改一个普通字段，于是把明文字符串直接发给服务器。
- 数据库里该字段变成明文，后续读取时解密失败或返回空值
- 没有错误、没有日志、没有告警，静默破坏数据安全性
- 哪怕字段已在
schemaMap中声明为encrypt，也不起作用
findOneAndUpdate 必须传完整文档并禁用 projection
这是唯一受支持的“安全更新”方式，但限制极多：驱动只对整个替换操作（即不带任何更新操作符的文档）做加密，且要求你显式提供全部字段值（包括未修改的字段）。
- 必须使用
replacement形式：findOneAndUpdate({ _id }, { ssn: "123-45-6789", name: "Alice", email: "a@example.com" }, { upsert: true }) - 不能省略其他字段，否则未传字段会被清空
- 必须确保
schemaMap已正确定义该 collection 的加密规则，否则加密不生效 - 避免传
projection选项，某些驱动版本下会干扰加密判断逻辑
更稳妥的做法：先读再写（find + replaceOne）
虽然多一次 round-trip，但语义清晰、行为可预测，适合业务逻辑复杂或字段较多的场景。
- 用
findOne({ _id })拿到当前文档（自动解密） - 在应用层修改目标字段（如
doc.ssn = "987-65-4321"） - 调用
replaceOne({ _id }, doc)—— 驱动识别出是全量替换，触发加密 - 注意检查
doc._id是否保留，否则可能插入新文档
容易被忽略的关键点
CSFLE 不是数据库功能，而是驱动行为；只要驱动没参与加解密，服务器永远只看到密文或明文——它自己完全不感知加密语义。这意味着：
- 任何绕过驱动的操作（mongosh 直接写、mongodump/mongorestore、聚合管道写入）都不会加密
- 事务内更新加密字段同样受限于上述规则，不支持
$inc、$push等操作符 - 如果你依赖远程
validator而非schemaMap，更新前务必确认服务器端 schema 仍有效且未被篡改
