动态字段应使用 updateOne() 配合 $set 局部更新，避免 save() 全量覆盖；键名含点号需确保为合法路径字符串；查询时用 $exists 结合具体条件（如 $gt: 0）更准确；聚合需用 $ifNull + $objectToArray 安全展开；ID 查询必须用 BSON.ObjectId 转换。
动态字段写入时，save() 和 updateOne() 行为差异在哪
MongoDB 不校验字段名合法性，但不同写法对嵌套结构、缺失字段的处理逻辑完全不同。用 save()（已弃用）会全量覆盖文档，哪怕只改一个动态字段，也可能意外清空其他运行时写入的字段；而 updateOne() 配合 $set 才真正支持“局部更新”。
- 场景：表单提交含用户自定义字段
custom_field_123，后端需追加而非替换整条记录 - 正确做法：始终用
updateOne({ _id: id }, { $set: { [`custom.${key}`]: value } })，把动态字段挂到custom子文档下，避免根级污染 - 坑：直接
{ [key]: value }解构进$set，若 key 含点号（如"address.city"），不加引号会导致 MongoDB 当成嵌套路径解析失败 —— 必须确保 key 是合法路径字符串，或提前用正则过滤非法字符
查询动态字段时，$exists 和 $ne: null 哪个更可靠
用户填了空字符串、0、false，这些值在 MongoDB 里都算“存在”，但业务上可能认为它们是“未填写”。仅靠 $exists: true 会漏掉这类情况；而 $ne: null 又会把 undefined 和缺失字段一起排除 —— 实际上两者语义不同，不能混用。
- 场景：筛选“所有包含评分字段且评分为正数”的表单记录
- 推荐组合：
{ "custom.rating": { $exists: true, $gt: 0 } }，既确认字段存在，又过滤掉 0 / null / "" - 性能注意：对
custom.rating单独建索引（db.forms.createIndex({ "custom.rating": 1 })），否则每次查动态字段都要全表扫描 - 坑：用
$type: "string"判断字段类型？不可靠 —— 用户可能存数字或布尔值，类型不固定时别依赖$type
聚合阶段里怎么安全展开未知字段名的 custom 子文档
当需要统计所有动态字段的出现频次，或把 custom 里的键值对转成数组，不能硬写字段名。MongoDB 的 $objectToArray 是唯一可行方案，但它要求输入必须是对象，如果某条记录 custom 是 null 或缺失，整个 pipeline 就会跳过该文档。
- 安全写法：先用
$ifNull补默认空对象，再进$objectToArray：{ $objectToArray: { $ifNull: ["$custom", {}] } } - 常见错误：
$unwind直接怼在$objectToArray结果上，但若数组为空（即custom确实为空），$unwind默认会丢弃该文档 —— 加preserveNullAndEmptyArrays: true参数才能保留 - 示例片段：
{ $addFields: { customPairs: { $objectToArray: { $ifNull: ["$custom", {}] } } } } { $unwind: { path: "$customPairs", preserveNullAndEmptyArrays: true } }
Node.js 驱动里，BSON.ObjectId 和字符串 ID 混用导致查不到数据
前端传来的 _id 几乎总是字符串，但 MongoDB 原生 ID 是 BSON.ObjectId 类型。直接拿字符串去查，即使内容一致也匹配不上 —— 这不是 bug，是类型严格匹配的结果。
- 检查方法：用
BSON.ObjectId.isValid(id)先判合法性，再用new BSON.ObjectId(id)转换；无效 ID（比如空串、超长乱码）转完会抛错，必须捕获 - 坑：用
mongoose.Types.ObjectId(id)替代原生驱动的BSON.ObjectId？不行 —— Mongoose 自己的类型在原生驱动查询里不被识别，必须用底层 BSON 包 - 建议：封装一个
toObjectId(id)工具函数，内部做isValid+ 构造，所有查询入口统一过一遍，避免散落在各处重复判断
动态字段最麻烦的从来不是存，而是查的时候忘了它根本没索引，或者字段名带点号没转义。别指望靠应用层拼字符串绕过，MongoDB 的路径语法就是这么认真的。
