Mongoose find 能查到 ID，aggregate 却返回空数组

同一个字符串 ID，Model.find() 能找到文档，换成聚合后却返回空数组：

await Comment.find({ _id: idText });
await Comment.aggregate([{ $match: { _id: idText } }]);

如果 _id 实际保存为 BSON ObjectId，且模型 schema 对应 ObjectId，这两个调用的参数处理并不相同。Mongoose 普通查询执行时会按 schema 转换过滤条件，聚合管道不会自动做同样的类型转换。

下面针对当前 Mongoose 的 aggregate()，使用 async / await。数据库把 _id 设计为字符串的项目不适用 ObjectId 转换；不能仅因为 ID 看起来像 24 位十六进制，就认定其存储类型。

比较实际 BSON 类型和最小管道

先确认连接的是同一数据库、同一模型集合，以及 schema 的字段类型。再在允许读取的范围内检查已知文档的实际 _id 类型，而不是只看接口 JSON 中的显示文字。ObjectId 序列化后常表现为字符串，但它在数据库里仍可能是 ObjectId。

把复杂管道暂时缩小到单独的 $match。如果前面有 $project、$group 或其他改变字段的阶段，匹配时的字段形态还可能已经不同，不能直接拿最初的 schema 推断它。

在应用边界构造 ObjectId

已确认该集合使用 ObjectId 标识时，在把外部字符串放入管道之前校验并转换。下面的函数接收已连接的模型，不建立新连接，也不修改文档：

import mongoose from 'mongoose';

async function findCommentById(Comment, idText) {
  if (typeof idText !== 'string' || !/^[0-9a-fA-F]{24}$/.test(idText)) {
    throw new TypeError('id must be a 24-character hexadecimal string');
  }

  const id = new mongoose.Types.ObjectId(idText);
  return Comment.aggregate([
    { $match: { _id: id } }
  ]).exec();
}

这里的格式校验是该接口接受 ID 的约定，不能证明数据库里一定存在这条记录。正确转换后仍返回空数组，是正常的“未匹配”结果之一；应继续核对 ID、集合及原本需要保留的业务过滤条件。

不要把 mongoose.Schema.Types.ObjectId 当成值构造器。它用于 schema 类型定义；管道中需要的是 mongoose.Types.ObjectId 构造出的 BSON 值。示例显式使用 new，不要照搬旧代码中省略它的写法。

实际接口还必须保留租户、权限等条件。为演示类型问题而简化的 _id 查询，不能代替完整的授权过滤器。

只转换模型约定为 ObjectId 的参数

聚合 $match 中其他 ObjectId 字段同样需要按其实际模型构造参数。例如 $in 接收一组 ID 时，应逐项完成格式校验和转换，再组成数组。不要把任意字符串都递归转换：订单号、外部系统 ID 和字符串类型的 _id 可能恰好也是 24 位十六进制文本。

也不必为了这个参数问题批量更改已存文档类型，或先把整个字段转成字符串后再比较。后者改变查询表达式及可能的索引使用，应在确有业务需求时另行评估。

区分查不到和查询失败

验收时至少核对：已存在的 ObjectId 字符串能匹配；格式合法但不存在的 ID 返回空数组；格式非法的输入在应用边界被拒绝；字符串标识的集合仍按字符串查询。再把经过确认的 $match 接回原管道，核对后续阶段没有丢弃结果。

聚合结果通常是普通 JavaScript 对象，不是完整的 Mongoose 文档实例，不能假定后续一定具有实例方法。这个返回形态差异也不意味着查询没有成功。

这是参数与查询层修正，不需要数据迁移。保留原查询代码及输入校验约定；回退时恢复应用版本，不修改集合里的标识来迎合某次查询。