不能直接用Array存KV对，因数据库无法识别k的字段语义，导致索引失效、查询低效、聚合复杂；应优先扩文档结构，动态场景推荐嵌套对象并严格校验key。
为什么不能直接用 Array 存 KV 对？
MongoDB 本身不阻止你存 [{k: "name", v: "Alice"}, {k: "age", v: 25}] 这种结构，但查询会立刻变痛苦：你想查 name = "Alice"，就得用 $elemMatch 配合字段路径，索引几乎无效，聚合也绕不开 $unwind —— 性能掉得快，还容易漏匹配。
根本问题在于：这种写法把“字段语义”藏在了值里，数据库无法感知 k 是逻辑字段名，自然没法建索引、做高效投影或类型校验。
实操建议：
- 除非 KV 键集合极小且完全不可预测（比如用户自定义标签），否则别用数组存 KV
- 如果只是偶尔新增几个字段，优先考虑直接扩 document 结构（加字段），MongoDB 完全支持 schema-free
- 真要动态，用嵌套对象比数组更友好：
{"profile.name": "Alice", "profile.age": 25}可建复合索引，也能用点号路径查
schemaless 文档中如何安全地增删动态字段？
直接 updateOne({ _id }, { $set: { [`custom.${key}`]: value } }) 是最常用做法，但有两个坑：一是 key 名含点号或美元符会报错；二是并发写同一 key 时可能覆盖非预期字段。
实操建议：
- 服务端必须对
key做白名单校验或正则过滤（例如只允许/^[a-zA-Z][a-zA-Z0-9_]*$/） - 避免用用户输入原样拼字段名，尤其禁用
$和.—— 否则$set: { "x.$where": ... }可能触发意外行为 - 如需原子性更新多个动态字段，用单次
$set而非多次请求，减少竞态 - 删除字段统一用
$unset: { "custom.key1": "", "custom.key2": "" }，别用null或空字符串代替
用 document 模拟 KV 表时，怎么建索引才有效？
如果你走的是 { custom: { name: "Alice", tags: ["vip"], score: 95 } } 这条路，索引不是不能建，而是得明确知道「查什么」。
常见错误现象：db.coll.createIndex({ "custom.tags": 1 }) 看似合理，但如果 tags 有时是数组、有时是字符串、有时缺失，索引选择性会崩，查询计划可能跳过它。
实操建议：
- 对高频查询字段单独建索引，例如
db.coll.createIndex({ "custom.score": 1 }) - 组合查询优先用前缀索引：比如常查
score > 80 AND tags: "vip"，就建{ "custom.score": 1, "custom.tags": 1 } - 避免对整个
custom对象建索引（{"custom": 1}），它只会索引顶层字段存在性，查不到内部值 - 用
explain("executionStats")确认实际用了哪个索引，别只看createIndex成功了就以为万事大吉
聚合阶段里展开动态字段，$objectToArray 的边界在哪？
$objectToArray 确实能把 { a: 1, b: 2 } 变成 [{k:"a",v:1},{k:"b",v:2}]，但它只接受对象，不接受 null/missing/数组 —— 一碰到就 pipeline 报错 "$objectToArray requires a non-null, non-array argument"。
使用场景有限：主要用在需要按 key 名做条件过滤（比如只取 k 匹配正则的项）、或转成数组后排序再取 topN。
实操建议：
- 前置加
$ifNull或$cond判断字段是否存在，例如：{ $objectToArray: { $ifNull: ["$custom", {}] } } - 别指望它替代 schema 设计：展开后再
$filter+$reduce性能远不如直接字段访问 - 如果目标是“找出所有文档中出现过的 custom key”，要用
$group+$addToSet配合$objectToArray，但注意内存限制（allowDiskUse: true得开）
动态字段本质是 trade-off：换来了灵活性，代价是查询能力下降、索引难设计、聚合变复杂。真正卡住的往往不是语法，而是没想清楚哪些字段真需要动态 —— 大部分业务里，“动态”其实只发生在配置层或标签系统，核心实体字段还是越稳定越好。
