MongoDB的schema校验仅在写入时生效，仅支持基础规则且不递归，无法替代应用层强类型检查；必须结合Zod等工具做双保险，并优化字段设计与索引。
MongoDB 存 JSON 配置时，schema 校验到底靠不靠谱
MongoDB 本身不强制 schema，但 4.0+ 支持 validator，能对插入/更新做基础校验。它不是 TypeScript，也不等价于运行时类型检查——只在写入时触发，且只校验字段存在性、类型、正则、范围等简单规则。
常见错误现象：db.collection.insertOne({ config: { timeout: "30s" } }) 通过了 validator（比如只写了 { timeout: { $type: "int" } } 却没设 required），结果应用读出来发现是字符串，直接炸。
- 必须显式声明
required字段，否则缺失字段不会报错 -
$type只认 BSON 类型名（如"string"、"int"、"object"），不识别 JS 的"number"或 TS 的number - 嵌套对象校验要展开写，
config.inner.timeout和config.inner是两回事，漏一层就失效 - 校验器不递归生效：即使你给
config设了$type: "object"，里面字段仍需单独校验
混合类型字段（如 value: string | number | boolean | null）怎么存又不失控
直接存成 any 类型字段最省事，但代价是查询和索引几乎废掉——MongoDB 无法为混合类型字段建有效索引，find({ value: 42 }) 可能扫全表，且聚合时容易因类型不一致崩在 $add 或 $concat。
真实使用场景：配置项支持“开/关”（boolean）、“毫秒数”（number）、“自定义文案”（string），但后端统一走一个 value 字段。
- 别用单字段存混合类型；拆成
value_string/value_number/value_boolean+value_type字段，写入前归一化 - 或用
value+value_kind（枚举值"string"/"number"/"boolean"），配合 validator 约束二者匹配 - 如果必须用单字段，至少加
$in校验：{ value_kind: { $in: ["string", "number", "boolean"] }, value: { $type: { $cond: [{ $eq: ["$value_kind", "string"] }, "string", { $cond: [...]} } } } }——但 MongoDB 不支持表达式里嵌套$type，所以这条路实际走不通，别试
强类型保障不能只靠数据库，得靠应用层“双保险”
靠 validator 拦住明显非法数据有用，但拦不住语义错误。比如 retry_count: -5 符合 $type: "int" 和 $gte: 0，但如果漏了 $gte 就穿过去了；再比如 host: "http://x.com" 过了字符串校验，但业务要求必须是域名格式。
真正落地的方案是：数据库校验做兜底（防脏写），应用层用 Zod / Yup / io-ts 做完整解析 + 转换，失败直接拒收请求。
- Node.js 示例：收到 POST
{ config: { timeout: 30, mode: "fast" } }，先用 Zod schema 解析，失败返回 400；成功后再塞进db.collection.insertOne() - 关键点：Zod 的
.passthrough()或.strict()要按需开，避免意外放过多余字段 - 别把校验逻辑分散在 Controller 和 Model 两层——统一收口在 DTO 解析环节，否则容易漏
- 如果用 Mongoose，
schema.pre("save")里调 Zod 是冗余的，Mongoose 自己的 validators 已够用，重点补它不支持的逻辑（如跨字段约束）
查配置时，$jsonSchema 不影响查询性能，但字段设计不当会拖垮
validator 本身不参与查询，不影响 find 速度。真正慢的是你设计的字段结构：比如把整个大配置对象存成单个 config 字段，然后频繁 find({ "config.features.auth": true })，MongoDB 就得反复解包 BSON 对象。
性能敏感场景（如网关配置实时拉取）下，扁平化字段比嵌套 JSON 更友好。
- 把深层路径转成点号字段：
config.features.auth→config_features_auth，加索引后查询快 3–5 倍 - 高频查询字段务必单独建索引，
db.collection.createIndex({ config_features_auth: 1 }) - 大配置（>16MB）别硬塞进单文档；拆成
config_meta+config_data两个集合，后者用config_id关联 - 别依赖
$expr做复杂 JSON 解析查询，像{ $expr: { $eq: [{ $type: "$config.timeout" }, "int"] } }是全表扫描，线上慎用
最常被忽略的一点：validator 里写的正则如果太宽泛（比如 /^.+$/），或者用了 $where，会显著拖慢写入——写入量大的配置服务，这点延迟会累积成瓶颈。
