$unwind易拖垮性能因会指数级放大文档量，必须前置$match过滤并建合适索引；优先用$size、$arrayelemat等替代展开，避免无谓扩容。
为什么$unwind容易拖垮聚合性能
$unwind 本身不慢，但它的副作用很致命：它会指数级放大文档数量。比如一个订单含 50 个商品项，$unwind 后就变成 50 份相同订单头信息 + 单个商品的文档。后续每个阶段（尤其是 $group、$sort）都要处理这 50 倍的数据量，内存和 CPU 压力陡增。
更隐蔽的问题是：如果 $unwind 前没做有效过滤，原始集合里有 10 万订单，其中 9 万根本不需要展开（比如状态不是 "shipped"），那这 9 万 × 平均 30 个商品 = 270 万无意义文档，全被喂给了管道下游。
必须前置的$match——不是建议，是硬性要求
在 $unwind 之前，所有能缩小数据集的 $match 都得放上去，且字段必须命中索引。否则 $unwind 就是在给垃圾数据“扩容”。
- 错误写法：
$unwind→$match→$group（已生成大量中间文档才开始过滤） - 正确顺序：
$match（按订单状态、时间范围等粗筛）→$match（再按数组长度或关键子字段细筛，如"items.0.productId"）→$unwind - 索引要覆盖
$match条件 +$unwind字段路径，例如对orders集合，建复合索引：{ status: 1, createdAt: 1, "items.productId": 1 }
用$size或$arrayElemAt代替$unwind做轻量判断
很多场景其实并不真需要“展开”，只是想查“有没有某个商品”或“第一个商品是什么”。这时候硬上 $unwind 是杀鸡用牛刀。
- 判断数组是否包含某值：
{$match: {"items.productId": "abc123"}}（直接走索引，不展开） - 取首个商品信息：
{$project: {firstItem: {$arrayElemAt: ["$items", 0]}}}（避免生成多文档） - 统计订单含多少商品：
{$project: {itemCount: {$size: "$items"}}}（纯计算，零展开） - 只对非空数组展开：
{$match: { "items.0": { $exists: true } }}（提前剔除空数组文档）
$unwind + $lookup 的组合必须加preserveNullAndEmptyArrays: false
当 $unwind 后紧跟 $lookup 关联另一张表时，若原始数组为空或 null，$unwind 默认会丢弃该文档（preserveNullAndEmptyArrays: false 是默认行为）。但很多人误设为 true，导致文档被保留却产生大量 null 关联结果，后续 $match 或 $group 要额外处理这些脏数据。
更关键的是：MongoDB 在 $lookup 后接 $unwind 时会自动优化合并阶段，但反过来（$unwind 后接 $lookup）**不会**自动优化。所以务必确认你写的 $unwind 是真有必要，而不是因为习惯性套模板。
真正难处理的，永远不是语法怎么写，而是想清楚——这个数组，我到底需不需要把它“摊开”成独立行；如果只需要摘要、计数或单个元素，$unwind 就是第一个该砍掉的阶段。
