$unwind 本身不直接 OOM但会因文档倍增放大内存压力，尤其与$group连用时；需前置$match、精简$project、对齐结构体类型，并避免依赖allowDiskUse。
$unwind 本身不直接 OOM，但会放大内存压力
$unwind 阶段不会单独触发 OutOfMemoryError，但它把“1 个文档 × 1 个数组（含 N 个元素）”变成“N 个文档”，文档数量呈倍数膨胀。如果原始文档大、数组长、又没前置控制，后续阶段（尤其是 $group 或 $sort）就会加载远超预期的数据进内存。
典型场景：logs 集合中单文档平均 8KB，events 字段是长度为 50 的嵌套对象数组；$unwind: "$events" 后，1 条变 50 条 → 单文档等效体积从 8KB 变成 400KB。再跟 $group 一起用，700 条原始文档就轻松突破 100MB 内存上限。
- 数组字段越深、嵌套越复杂（如
user.orders.items[].tags），$unwind后单文档复制开销越大 -
$unwind遇到null或缺失字段时默认丢弃整条文档——表面看数据少了，实则可能掩盖了因结构体反序列化失败导致的字段膨胀（比如 Go 中仍用[]T解码单值，BSON 解码器填充nil后又隐式扩容） - 在事务中用
$unwind不报错，但若上游没$match过滤，事务持有读锁时间拉长，间接加剧 GC 压力（尤其 Java/Go 客户端缓存大量 BSON 字节）
Go 应用里 $unwind 后结构体定义不匹配是隐形炸弹
很多 OOM 表现为客户端堆溢出（如 java.lang.OutOfMemoryError: GC overhead limit exceeded），根源不在 MongoDB 服务端，而在 Go/Java 等语言层：你用 []User 去 unmarshal $unwind 后的单对象字段，驱动无法匹配类型，底层反复尝试分配、重试、丢弃，最终撑爆本地内存。
例如 MongoDB 返回 {"user": {"name": "Alice"}}，但你的结构体仍定义为 User struct { User []User `bson:"user"` } —— BSON 解码器会把 {"name": "Alice"} 当作空数组处理，或 panic 后 fallback 到低效路径，日志里看不到明显错误，只看到 GC 时间飙升。
- 必须为
$unwind后结果定义专用结构体，把原数组字段改为单值：User User `bson:"user"` - 使用
mongo-go-driver时，避免在聚合后直接Decode()到旧结构体；先Decode(&raw bson.M)检查字段类型，再映射 - 如果数组字段可能为空，加
preserveNullAndEmptyArrays: true选项，否则文档直接消失，分组统计漏数，你还以为是逻辑 bug
$unwind + $group 是内存杀手组合
$unwind 后立刻 $group，等于强制 MongoDB 把所有展开文档全 load 进内存做分组。它不像 $match 可下推、也不像 $project 能裁剪——$group 必须看到全部输入才能开始归并。
比如统计每个用户的活跃设备数：$unwind: "$devices" → $group: {_id: "$userId", count: {$sum: 1}}，若某用户有 2000 个设备，就生成 2000 行中间数据；1000 个这类用户，就是 200 万行，哪怕每行只有 200 字节，也超 400MB。
- 务必在
$unwind前加$match，过滤掉不需要展开的文档（如只查近 7 天数据） - 考虑用
$size替代$unwind+$sum：若只需数组长度，{$project: {deviceCount: {$size: "$devices"}}}零内存膨胀 - 真要展开再分组，把
$unwind放在复合索引字段之后，并确保$group键是高基数字段（避免单个_id聚合几万条）
allowDiskUse 对 $unwind 场景效果有限
开了 allowDiskUse: true 并不能缓解 $unwind 导致的 OOM，因为磁盘暂存只作用于 $sort 和 $group 阶段的中间结果，而 $unwind 本身的文档复制发生在内存中，且不可卸载到磁盘。
更麻烦的是：$unwind 后文档量暴增，即使 $group 用了磁盘，网络传输和客户端解码压力一点没少——MongoDB Atlas M0 免费版甚至禁止 allowDiskUse，此时你连兜底都没得选。
- 不要指望
allowDiskUse救$unwind，它只是让$group不 crash，不解决膨胀源头 - 真正有效的控制点只有三个：
$match前置、$project精简、结构体类型对齐 - 最难调的其实是那些字段动态生成、数组长度不可控的集合（比如日志中的
metadata.tags）——这时候宁可拆成两次查询：先distinct取 ID，再按批$in查详情
