mongodb支持不规则数据是设计常态，但需归一化处理：用$rename、$set、$unset批量修正字段；聚合管道优于map-reduce；避免$unwind前未校验数组长度；拆分操作须分步执行，禁用聚合中写入。
不规则数据在MongoDB里不是bug，是常态
MongoDB原生支持字段动态增减、嵌套深度不一、数组长度不定的文档结构，这本身就是设计目标。但“支持”不等于“推荐直接用”。真实业务中遇到的不规则，往往来自日志采集、爬虫入库、IoT设备上报等场景——字段名拼错、rm和msgType混用、subMs有时是数组有时是null、甚至出现"1"这种字符串键名的伪对象。这类数据没法靠索引加速查询，聚合时容易$unwind报错，Map-Reduce更会因游标未耗尽直接卡死。
先用$set + $unset做轻量级结构归一
90%的“不规则”其实只是字段命名或存在性不一致，没必要上聚合管道。优先用updateMany批量修正：
- 把所有
rm字段重命名为message：{"$rename": {"rm": "message"}} - 把
null或缺失的subMs统一设为空数组：{"$set": {"subMs": {"$ifNull": ["$subMs", []]}}} - 删掉非法字段如
"1"这种数字字符串键：{"$unset": ["1", "services.1"]}
注意：这些操作必须在聚合或Map-Reduce前完成。否则$unwind遇到null会跳过整条文档，map函数里访问this.rm.content可能报TypeError。
聚合管道比Map-Reduce更适合现代结构转换
Map-Reduce在MongoDB 5.0+已标记为deprecated，且JavaScript引擎执行慢、无法利用索引、并发能力弱。处理不规则数据时，聚合管道的$cond、$switch、$map组合更可靠：
- 用
$switch区分不同结构的文档：{"$switch": {"branches": [{"case": {"$eq": ["$msgType", "URL"]}, "then": "$url"}, {"case": {"$eq": ["$mt", "TEXT"]}, "then": "$content"}], "default": null}} - 用
$map安全遍历subMs（即使为空或null）：{"$map": {"input": {"$ifNull": ["$subMs", []]}, "as": "item", "in": {"pid": "$$ROOT._id", "content": "$$item.rm.content"}}} - 避免
$unwind前没检查数组长度——加$addFields预判：{"$addFields": {"subMsCount": {"$size": {"$ifNull": ["$subMs", []]}}}}，再用$match: {"subMsCount": {"$gt": 0}}过滤
真正需要拆分集合时，别在单次聚合里插入新文档
像把subMs数组元素拆成独立文档这种操作，聚合管道本身不能写入其他集合（$out和$merge只能写回本集合或指定集合，但无法“一对多”生成新文档）。常见错误是想在map里调用db.m.insert()——这在聚合中完全不可用，也会破坏原子性。
正确做法分两步：
- 第一步：用聚合输出标准化后的数组数据到临时集合，例如
db.m.aggregate([{"$project": {"subMsFlat": {"$map": {...}}}}, {"$unwind": "$subMsFlat"}, {"$merge": {"into": "sub_ms_temp"}}]) - 第二步：用
bulkWrite批量插入正式集合，同时补全pid和index字段，比逐条insertOne快一个数量级
最容易被忽略的是游标生命周期——如果用find().forEach()边读边插，又没显式调用it.hasNext()耗尽游标，后续插入操作可能导致游标状态错乱，尤其在分片集群上会静默失败。
