Mongoose更新索引字段后find/findById无法获取文档问题

我们有一个包含多字段的Client模型，该集合设置了三个索引，示例Schema如下：

Client {
   _id: uniqueId, // indexed
   email: string  // indexed
   pI: {}
   ...
   ...
   isDeleted: {
     type: boolean,
     index: true
     default: false
   }
}

该模型已使用多年，经多人维护，其他相关逻辑均正常。问题在于：当将isDeleted字段设为true后，使用find或findById查询该文档时无法返回结果（提示找不到客户端）；将其改回false后可重新查询到。此问题仅出现在索引字段上，而使用聚合框架可正常查询isDeleted为true或false的文档，请问这是什么原因？

核心原因：Mongoose模型的全局查询中间件自动过滤软删除文档 #

这种现象的最直接原因是你的Client模型被添加了前置查询中间件（pre hook），它会自动给所有find/findById/findOne这类Mongoose查询方法附加{ isDeleted: false }的过滤条件。而MongoDB的聚合框架（aggregate）属于原生操作，不会触发Mongoose层面的这类中间件，因此能正常返回所有状态的文档。

验证方法 #

1. 绕开Mongoose，直接在MongoDB Shell中执行原生查询：

db.clients.find({ _id: "目标文档ID", isDeleted: true })

如果能查到目标文档，就可以确认是Mongoose中间件在起作用。

2. 在代码中手动指定isDeleted条件，覆盖默认过滤规则：

// 强制查询已删除的文档
Client.findById("目标文档ID", { isDeleted: true })
// 或者取消isDeleted的过滤限制
Client.findById("目标文档ID").where('isDeleted').exists(true)

如果这样能成功查到文档，也能验证中间件的存在。

排查步骤 #

检查Client模型的代码文件，是否存在类似以下的中间件配置：

clientSchema.pre(['find', 'findOne', 'findById'], function() {
  this.where({ isDeleted: false });
});

这是实现软删除功能的常见方式，会自动过滤标记为已删除的文档，但仅作用于Mongoose提供的查询方法，不会影响聚合操作。

解决思路 #

• 如果需要查询已删除的文档，在调用find/findById时手动添加isDeleted: true的查询条件即可。
• 如果不需要全局自动过滤已删除文档，可以移除对应的前置查询中间件，但要提前评估该操作对现有业务逻辑的影响。

内容的提问来源于stack exchange，提问作者Apoorva Chikara