MongoDB聚合中用$addFields+$indexOfArray为ID列表添加排序权重，先$match过滤再计算下标作为__sortOrder字段，$sort按其升序排列，最后$project剔除该临时字段。
用 $addFields + $indexOfArray 给 ID 列表打排序权重
MongoDB 本身不支持按任意顺序对 _id 字段做 IN 查询并保持输入顺序返回。聚合管道里得自己造一个“序号字段”。核心思路是：把目标 ID 列表传进去，用 $indexOfArray 查每个文档 _id 在该列表里的下标，作为排序依据。
常见错误是直接在 $match 后用 $sort 硬排，结果顺序完全不对——因为 $sort 只认字段值，不认识你传进去的数组顺序。
- 确保传入的 ID 列表是完整、去重、且类型一致的（比如全是
ObjectId，别混着字符串） -
$indexOfArray对不存在的_id返回-1，建议加$match先过滤，避免无效数据干扰排序 - 如果 ID 列表很长（比如上万），
$indexOfArray性能会下降，此时应优先考虑应用层拼序或用临时集合
[
{ $match: { _id: { $in: [ObjectId("..."), ObjectId("...")] } } },
{ $addFields: { __sortOrder: { $indexOfArray: [[ObjectId("..."), ObjectId("...")], "$_id"] } } },
{ $sort: { __sortOrder: 1 } }
]
处理字符串 ID 时必须显式转 ObjectId 或统一类型
如果你的 ID 列表是字符串形式（比如从 HTTP 请求里拿到的 ["60a1b2c3...", "60a1b2c4..."]），而库中存的是 ObjectId，直接塞进 $indexOfArray 会全匹配失败，__sortOrder 全是 -1。
不是所有驱动都自动帮你转类型；MongoDB Server 也不懂“看起来像 ObjectId 的字符串就该当 ObjectId 用”。
- 在应用层提前把字符串数组 map 成
ObjectId实例再传给聚合（Node.js 用new ObjectId(str)） - 或者在聚合里用
$cond+$toString做双向转换（仅限 MongoDB 4.0+，且有性能损耗） - 更稳妥的做法：查之前先确认集合中
_id的实际存储类型，别假设
$sort 阶段必须跟在 $addFields 后，且不能依赖索引
这个自定义排序不走索引。即使你在 _id 上建了索引，__sortOrder 是运行时算出来的字段，MongoDB 不会为它生成索引，$sort 就是内存排序。
容易踩的坑是以为加了 { _id: 1 } 索引就能加速这个流程——没用。排序依据不是 _id，而是计算字段。
- 数据量大时（比如匹配出几千条），注意
allowDiskUse: true，否则可能报Sort exceeded memory limit - 如果只是偶尔查几十个 ID，影响不大；但要是高频调用、每次几百 ID，就得评估是否值得在应用层做二次排序
- 别在
$addFields前加$sort，那等于白干——顺序还没打上呢
聚合输出要删掉临时字段，否则容易引发下游解析错误
__sortOrder 这种临时字段，不该出现在最终返回给前端或业务逻辑的数据里。尤其当你用 ODM（比如 Mongoose）时，多一个字段可能触发 schema 校验失败或序列化异常。
这不是可选项，是必做清理动作。
- 在最后加一个
$project把__sortOrder: 0掉（或显式列出需要的字段） - 如果用了
$lookup后续阶段，注意$project要放在整个流水线末尾，不然中间阶段可能依赖这个字段 - 某些旧版驱动对字段名含下划线敏感，命名时避开
__开头更稳妥（比如叫sort_idx）
真正麻烦的从来不是怎么写这条聚合，而是谁来保证每次传进来的 ID 列表既合法又有序，以及当列表为空或含重复 ID 时，后端有没有兜底逻辑——这些地方最容易漏测。
