MongoDB的Schema验证是服务端校验机制，仅在insert/update时触发，需显式启用validator并设validationLevel:"strict"和validationAction:"error"才真正拦截非法文档；它不替代应用层校验，也不影响find/delete，且不支持完整JSON Schema（如$schema、oneOf等），存量数据和索引不受其影响。
什么是MongoDB的Schema验证，它真能拦住脏数据？
不能完全拦住，但能大幅降低脏数据写入概率。MongoDB的Schema验证是服务端校验机制，只在insert和update操作时触发，且仅对启用了验证规则的集合生效。它不替代应用层校验，也不影响find或delete——这点常被误认为“开了验证就万事大吉”。
关键前提是：必须显式启用，且规则需通过collMod或创建集合时指定validator字段，否则即使写了规则也无效。
怎么给现有集合添加Schema验证规则？
直接用runCommand调用collMod最稳妥，避免重建集合。注意：规则默认是宽松模式（validationLevel: "warn"），这意味着写入失败不会发生，只会记录日志——这正是多数人踩坑的起点。
- 把
validationLevel设为"strict"才真正拦截非法文档 -
validationAction必须设为"error"（而非"warn"），否则写入仍会成功 - 规则本身写在
validator字段里，支持JSON Schema语法，但MongoDB只实现子集（比如不支持$schema关键字）
示例：强制email字段存在、为字符串、匹配邮箱格式：
db.runCommand({
collMod: "users",
validator: {
$jsonSchema: {
required: ["email"],
properties: {
email: {
bsonType: "string",
pattern: "^.+@.+\..+$"
}
}
}
},
validationLevel: "strict",
validationAction: "error"
})
JSON Schema里哪些字段MongoDB不支持？
MongoDB的$jsonSchema不是完整实现，几个高频不支持项必须避开：
-
$schema、$id等元关键字——解析直接报错：Invalid JSON schema: unknown keyword "$schema" -
additionalProperties: false虽可用，但若文档含_id（自动插入）或其它服务端生成字段，可能误判为非法 - 不支持
oneOf、anyOf、not等复杂逻辑组合，会返回Unrecognized expression '$jsonSchema' -
bsonType: "date"要求值是ISODate对象，传字符串会失败；而bsonType: "string"配pattern才是校验时间字符串的常用做法
为什么有些更新操作绕过了Schema验证？
三种典型绕过场景：
- 用
updateMany更新时没带upsert: true，但匹配不到文档——操作看似成功，其实什么都没做，验证根本没触发 - 使用
$set只更新部分字段，而验证规则依赖其他字段（如required: ["status", "updated_at"]），此时MongoDB只校验最终合并后的文档，不是增量字段 - 驱动程序版本太老（如Node.js driver writeConcern，导致某些验证错误被静默吞掉，需显式配置
w: "majority"
验证是否生效，最直接方式是手动插一条违规数据，看是否返回WriteError和具体errmsg字段，而不是只看返回的acknowledged: true。
真正难的是规则迭代：业务字段变多、类型变复杂后，$jsonSchema容易变成维护负担。与其堆砌长规则，不如在应用层用Zod或Joi做前置校验，数据库验证只守底线——比如非空、基础格式、关键枚举值。
