多层$unwind是聚合性能杀手，因文档数呈乘积级爆炸增长，需每层后立即$match过滤、用$size限长、避免无脑展开，并通过explain("executionStats")监控memUsage防超限。
多层 $unwind 是聚合性能杀手，不是写法错，而是数据爆炸没被意识到——每层都可能让文档数翻 N 倍，内存和 CPU 都扛不住。
为什么 $unwind 套娃会让查询慢到卡死
第一层 $unwind 把 1 个含 5 个元素的数组展开成 5 个文档；第二层再 $unwind 一个嵌套数组（比如每个元素里又有 3 个子项），就变成 5 × 3 = 15 个文档；第三层再套一层 4 元素数组？就是 60 个。这不是线性增长，是乘积级膨胀。
- 实际日志中常见
totalDocsExamined突然跳到几百万，但nReturned只有几百——explain("executionStats")一眼就能揪出这个信号 -
$unwind后不跟$match过滤，等于把所有爆炸后的中间文档全喂给后续阶段 - 如果某层
$unwind字段经常是空数组或null，默认会丢弃整条文档（除非加preserveNullAndEmptyArrays: true），但这也意味着你本想保留的逻辑被悄悄绕过了
必须在每层 $unwind 后立刻加 $match
不能只在开头 $match 一次就完事。每展开一层，都要用该层字段做一次筛选，把“无效分支”提前剪掉。
- 比如处理订单 → 商品 → SKU 层级：先
$unwind: "$items"，紧接着就要$match: {"items.status": "shipped"}，而不是等三层展开完再筛 - 如果某层字段值分布极不均匀（如 95% 的
items数组长度为 0 或 1），考虑先用$filter预处理数组，再$unwind，避免大量空展开 - Go 或 Python 驱动里传参时，注意结构体字段类型要匹配：
$unwind后items是单对象，别还用[]Item去反序列化，否则解出来全是null
用 $project + $size 控制爆炸规模
当无法避免多层 $unwind，又不确定数组大小时，得主动设限，防止失控。
- 在第一层
$unwind前，先$project出数组长度：{"itemsCount": {"$size": "$items"}}，再$match: {"itemsCount": {"$lte": 10}}—— 把超长数组的文档直接过滤掉 - 对深层嵌套，比如
"items.variants"，可用$arrayElemAt或$slice取前 N 个，而不是无脑展开全部 - 如果业务允许近似结果（比如统计“最多前 5 个 SKU 的销量”），就别硬刚全量
$unwind，改用$reduce或$sum在数组内聚合
allowDiskUse 不是救命稻草，是预警灯
开了 {allowDiskUse: true} 不代表问题解决，只代表 MongoDB 愿意把内存撑爆后写磁盘——而磁盘 I/O 波动会让响应时间从 200ms 跳到 8s，且不可预测。
- 只要管道里出现两层及以上
$unwind，就必须跑explain("executionStats")查memUsage；超过 50MB 就该警惕 - 如果
memUsage接近 100MB，说明你已经在悬崖边了：要么砍掉一层$unwind，要么把部分逻辑拆到应用层分批处理 - 生产环境必须显式传
{allowDiskUse: true}，否则遇到内存超限直接报"Exceeded memory limit"，而不是静默降级
真正难的不是写出能跑的聚合，而是预判哪一层 $unwind 会让文档数突破临界点。每次加新层前，先用小样本 $limit: 10 加 explain 看爆炸系数，比上线后查慢日志快十倍。
