Mongoose聚合操作使用$match阶段返回空数组如何解决

按优先级从高到低排查以下问题即可解决：

1. 匹配字段类型不匹配（占这类问题的80%） #

你在$match里把入参id转成了ObjectId类型，但首先要确认Comments集合里article_id的实际存储类型：

• 如果Schema里没给article_id显式指定Schema.Types.ObjectId类型，或者之前写数据时误存成了字符串，MongoDB不会做隐式类型转换，拿ObjectId匹配字符串字段必然返回空。不要想当然觉得字段类型是对的，这类问题绝大多数人查完最后发现都是类型存错了。
• 排查方法：直接查库看一条评论的article_id字段类型，如果是字符串，去掉Types.ObjectId()包装直接传字符串id即可：

'$match': {
  'article_id': id
}

• 如果确定要存ObjectId类型，务必在Schema里明确定义字段类型，避免后续写入时出现类型错乱。

2. $unwind默认行为过滤了所有匹配到的文档 #

你在$match之后直接对replies字段做$unwind，这里有个非常容易踩的坑：$unwind默认会把被展开字段为null、不存在、是空数组的文档直接从管道里剔除。
如果你$match筛选出来的对应文章下的评论，刚好全是没有回复（replies为空数组）的状态，经过这一步所有匹配到的文档都会被过滤干净，最后返回空数组，非常容易误以为是$match阶段没生效。
修复方式：给所有$unwind阶段加上preserveNullAndEmptyArrays: true配置，保留空值文档：

{
  '$unwind': {
    path: '$replies',
    preserveNullAndEmptyArrays: true
  }
}

你管道里后续展开replies.sender、replies.receiver、commentDetails、user的几个$unwind阶段，如果对应字段可能为空，都要加上这个配置，否则都可能出现文档被意外过滤的问题。

3. 入参id本身非法 #

先打印传入的id做校验：

• 如果id是undefined、空字符串、或者不符合24位十六进制格式的非法ObjectId字符串，Types.ObjectId(id)要么报错，要么生成一个库中不存在的ObjectId，自然匹配不到数据。
• 加一层前置校验即可：

const mongoose = require('mongoose');
if (!mongoose.isValidObjectId(id)) {
  return []
}

额外优化建议 #

你当前的聚合管道有大量重复逻辑：两次做「关联comments表→合并replies→替换根节点」的操作，完全可以简化，减少管道阶段既能提升性能，也能降低中间环节意外过滤数据的概率。比如关联回复发送方、接收方的逻辑可以合并处理，不需要分两次group回表。

内容的提问来源于stack exchange，提问作者Akezhan Issadilov