$unwind仅扁平化数组，不过滤或重组，必须配合$match或$filter清理空/null/缺失值，并注意路径写法、字段保留与性能风险。
$unwind 是处理嵌套数组扁平化的第一且最常用步骤，但它本身不“过滤”或“重组”，只负责把每个数组元素拆成独立文档。直接用 $unwind 而不配合后续阶段，极易导致数据膨胀、重复字段、空值报错。
为什么 $unwind 后必须跟 $match 或 $filter？
数组字段可能为空、null 或缺失，$unwind 遇到这些情况默认会丢弃整条文档（除非加 preserveNullAndEmptyArrays: true）。但即使保留，也会生成无意义的空记录。
- 空数组
[]→ 加preserveNullAndEmptyArrays: true后产出一条{ tips: null }文档 -
"tips": null→ 同样产出{ tips: null } - 字段根本不存在 → 默认被丢弃；加
preserveNullAndEmptyArrays: true后产出{ tips: null }
所以真实场景中，几乎总要先清理再展开：$set + $filter 预筛数组，或 $unwind 后立刻 $match: { "tips._id": { $exists: true } }。
$unwind 的路径写法和常见错误
路径必须以 $ 开头且指向数组字段，不能是表达式或计算字段（除非先用 $set 提前构造）。
- ✅ 正确：
{ $unwind: "$tips" }、{ $unwind: "$details" } - ❌ 错误：
{ $unwind: "tips" }（缺$） - ❌ 错误：
{ $unwind: "$tips._id" }（_id不是数组） - ❌ 错误：
{ $unwind: { path: "$tips", includeArrayIndex: "idx" } }（语法过时，4.2+ 必须用对象写法）
如果要用索引字段，正确写法是：{ $unwind: { path: "$tips", includeArrayIndex: "tipIndex" } } —— 注意 path 是必需键，includeArrayIndex 是可选键。
扁平化后如何还原父文档关键字段？
$unwind 拆出的每条记录仍携带原文档所有非数组字段（如 _id、name、teach_id），这是优势，但也是陷阱：容易在 $group 时误把父级字段当分组依据。
- 想按子文档字段分组？用
$group: { _id: "$tips._id" }，别写成_id: "$_id" - 需要同时带出父文档名？
$project里显式保留：name: 1, "tipName": "$tips.tip_name" - 担心字段名冲突（比如子文档也有
id）？提前重命名：parentId: "$_id", tipId: "$tips._id"
特别注意：$unwind 后若不做 $project 或 $replaceRoot，原始嵌套结构（如 {"tips": {...}}）依然存在，只是 tips 变成了单个对象而非数组 —— 这不是真正“去包装”，只是“解包一步”。
性能与数据量爆炸风险
一个含 100 个元素的 details 数组，$unwind 后变成 100 条文档。若集合有 1 万条这样的文档，管道中间结果就是 100 万条 —— 很快触发 aggregation memory limit（默认 100MB）。
- 务必在
$unwind前用$match尽量缩小输入集 - 考虑用
$limit控制输出规模（调试时尤其有用） - 生产环境对大数组，优先评估是否真需全量展开；有时
$filter+$arrayElemAt更轻量
真正的扁平化从来不是只写一行 $unwind 就完事；它是展开、清洗、重投射、去重、聚合这一整条链路的协同，漏掉任意一环，得到的都不是业务要的“那组干净子文档”。
