MongoDB需用$objectToArray将动态键转数组再匹配，因不支持键名通配符查询；须先处理null/缺失字段，再对k（键名）或v（键值）操作，推荐在$match中用$regexMatch提高性能。
用 $objectToArray 把动态键转成数组再匹配
MongoDB 不支持直接对键名做通配符查询（比如 {"user.*.status": "active"} 这种写法无效），必须先把对象结构“拍平”。核心思路是：把文档中不确定的键名，通过 $objectToArray 转成键值对数组，再用 $filter 或 $anyElementTrue 筛选。
常见错误是试图用 $regex 直接套在字段路径上，结果查不到任何数据——因为 $regex 只匹配字段值，不匹配字段名本身。
-
$objectToArray只接受对象类型输入，如果目标字段可能是null或缺失，得先用$ifNull或$cond处理，否则整个 pipeline 会跳过该文档 - 转换后数组元素形如
{ k: "2024-01", v: { status: "done" } }，后续匹配要针对k字段（键名）或v字段（键值）分别操作 - 如果只关心“是否存在某个模式的键”，用
$anyElementTrue+$regexMatch最轻量；如果还要取出对应值，就得用$filter
匹配键名含日期格式的字段（如 "2024-01"、"2024-02"）
这是最典型的动态键场景：按月/按天存储的嵌套数据。不能靠 find({ "data.2024-*": { $exists: true } }) —— MongoDB 不解析通配符路径。
正确做法是在聚合中构造正则匹配键名：
[
{
"$addFields": {
"dataEntries": { "$objectToArray": "$data" }
}
},
{
"$match": {
"dataEntries.k": { "$regex": "^202[4-9]-[0-1][0-9]$" }
}
}
]
注意："dataEntries.k" 是数组字段，$regex 在这里会隐式执行数组元素遍历（等价于 $elemMatch），但仅限 $match 阶段；到了 $project 里就不能这么写了。
- 正则写在
$match里比写在$filter里快，因为能利用索引（如果dataEntries.k被建了多键索引） - 如果
data字段非常大（几百个键），$objectToArray会产生大量中间数据，影响内存和性能，建议先用$limit控制样本量调试 - 避免用
$regex匹配任意字符串（如".*report.*"），容易误命中，优先用前缀锚定（^report_）
从匹配到的动态键中提取对应值并展开
光知道“有符合模式的键”不够，多数时候要拿到那个键下面的值（比如 data["2024-01"].score）。这时候不能只靠 $match，得用 $filter + $arrayElemAt 抽出来。
示例：取第一个匹配 2024- 开头的键对应的 v.score
[
{ "$addFields": { "entries": { "$objectToArray": "$data" } } },
{
"$addFields": {
"matchedEntry": {
"$arrayElemAt": [
{ "$filter": {
"input": "$entries",
"cond": { "$regexMatch": { "input": "$$this.k", "regex": "^2024-" } }
}
},
0
]
}
}
},
{ "$project": { "score": "$matchedEntry.v.score" } }
]
-
$arrayElemAt取0是为了防数组为空时报错，但如果业务上必须存在，建议加$cond判断$matchedEntry是否为null - 不要在
$project里重复调用$objectToArray，它开销大，一次转换、多次复用 - 如果需要所有匹配键的值（不止第一个），就别用
$arrayElemAt，直接$map遍历$filter结果
聚合结果无法直接用于 update？得用 updateMany + pipeline 表达式
很多人做完聚合确认逻辑对了，想顺手更新文档，却发现 updateOne 不接受完整聚合 pipeline。其实从 MongoDB 4.2 起，updateMany 的第二个参数支持 pipeline 语法，但写法和 aggregate 有差异。
关键区别：update 中的 pipeline 不能用 $match 做筛选（那是 filter 参数的事），只能用 $set / $unset 等更新操作符，且所有表达式都必须基于当前文档上下文。
- 例如：把所有
data中2024-开头的键的status改为"archived"，得用$set+$map+$cond重建整个data对象 - 这种更新不可逆，务必先在小集合上测试，尤其注意
$map里漏掉原键会导致数据丢失 - 如果只是补一个字段（比如加
latestMonth），比重构整个对象安全得多，优先考虑这类降级方案
真正麻烦的不是语法，而是动态键场景下，你永远没法保证所有文档的 data 结构一致——有人缺字段，有人多嵌套，有人存的是字符串不是对象。验证输入类型比写匹配逻辑花的时间还多。
