$unwind 不保证保留原始数组顺序，必须配合 includeArrayIndex、$sort 和 $group 才能可靠还原；Go 解析时需用单值字段而非切片，否则解码失败导致顺序误判。
$unwind 本身不保证保留原始数组顺序
这是最常被误解的一点：$unwind 操作符只负责“展开”数组，它不承诺维持元素在原数组中的位置顺序。MongoDB 官方文档明确说明：其行为是按 BSON 数组的存储顺序逐个产出文档，而该顺序在多数情况下与插入顺序一致——但一旦发生数组字段被 $push、$set 或更新操作修改过，BSON 层面的物理顺序就可能已不可靠。
更关键的是，$unwind 后若没立刻接 $sort，后续任何阶段（包括 $group、$limit）都可能因执行计划变化、分片路由、或并行处理导致输出顺序浮动。
- 原始数组
["a", "c", "b"]经$unwind后，理论上应输出三条文档，但不加$sort时，你无法依赖它们一定按a → c → b的顺序出现 - 如果数组来自
$addToSet或去重逻辑，其内部顺序本就不受控，$unwind只是忠实地摊开当前状态 - 使用
includeArrayIndex可以捕获下标（如{ $unwind: { path: "$tags", includeArrayIndex: "idx" } }），但这个idx字段必须显式参与后续$sort才能还原顺序
为什么只 $unwind + $group 无法恢复原始顺序
$group 阶段本身不保留输入文档顺序 —— 它按 _id 分组聚合，子项收集进 $push 数组时，MongoDB 不保证插入顺序与上游流顺序一致，尤其在分片或大数据量下。
即使你用 $push: "$$ROOT" 或 $push: "$tags"，得到的数组仍是“逻辑聚合结果”，不是“原始顺序快照”。这和 SQL 中 GROUP BY 后未用 ORDER BY 就直接 STRING_AGG 是一个道理。
- 错误写法：
$unwind → $group（无$sort）→ 输出数组顺序随机 - 正确路径：必须在
$unwind和$group之间插入$sort，且排序依据要是能反映原始顺序的字段（如idx或业务时间戳） - 若原始数组无序号字段，又想严格还原，唯一可靠方式是在写入时就存下索引，例如：
{"tags": [{"name":"a","idx":0}, {"name":"c","idx":1}, {"name":"b","idx":2}]}
Go 结构体映射错误会掩盖顺序问题
很多开发者发现“顺序乱了”，实际是 Go 解码时字段为 null，导致后续逻辑误判。这是因为 $unwind 后每个文档的数组字段（如 user）已变成单个对象，但结构体仍定义为 []User，BSON 解码失败后字段默认为零值，nil 或空切片 —— 此时你拿到的根本不是展开后的数据流，自然谈不上顺序。
- ❌ 错误结构体：
type Doc struct { User []User `bson:"user"` } - ✅ 正确结构体：
type UnwoundDoc struct { User User `bson:"user"` }（注意是单值，非切片） - 若需保留索引信息，结构体中还要加上
Idx int `bson:"idx"`字段来接收includeArrayIndex的值
真正可控的顺序还原方案
要确保最终结果顺序可预期，不能依赖 $unwind 的隐含行为，而要主动构造可排序依据。最轻量且通用的做法是组合 includeArrayIndex + $sort + $group。
示例管道片段：
[{"$unwind": {"path": "$items", "includeArrayIndex": "itemIdx"}}, {"$sort": {"_id": 1, "itemIdx": 1}}, {"$group": {"_id": "$_id", "items": {"$push": "$items"}}}]
-
includeArrayIndex必须写在$unwind对象内，不能省略path键 -
$sort必须包含原始文档标识（如_id）+ 索引字段，避免跨文档混序 -
$group后的$push才会按$sort后的流顺序收集，这才是“还原”的本质 - 如果原始数组很大，
$push可能触发 16MB BSON 限制，此时应改用$limit或分页处理，而非强求一次性还原
顺序不是默认属性，而是需要显式声明和维护的状态。只要漏掉 includeArrayIndex 或中间缺一次 $sort，你就已经失去了对顺序的控制权。
