MongoDB的聚合管道提供了强大的数据处理能力，而$match阶段往往是整条管道的第一道关卡。在使用$match过滤数组字段时，$nin操作符的语义和大多数人直观理解的不太一样。本文将从基本用法入手，逐步分析$nin在数组场景下的匹配规则、等价改写方式以及容易踩坑的地方，并给出可直接运行的示例代码。
$nin的基本语法与数组匹配规则
$nin的意思是"not in"，即筛选出字段值不包含在指定数组中的文档。它既可以用于普通查询的filter条件，也可以直接放在聚合管道的$match阶段中。语法形式为：
db.orders.aggregate([
{
$match: {
status: { $nin: ["cancelled", "pending"] }
}
}
])上面这条语句会保留status既不是cancelled也不是pending的文档。看起来很简单，但当字段本身是数组时，规则就变得微妙了。MongoDB对数组字段的匹配遵循"任一元素命中即命中"的原则：$in判断的是数组字段中是否存在至少一个元素落在给定集合内，而$nin恰好相反，它要求数组字段中没有任何一个元素出现在给定的集合里，同时还要求文档中确实存在该字段。
举个例子，假设集合中有如下文档：
// 文档A
{ _id: 1, tags: ["red", "blue"] }
// 文档B
{ _id: 2, tags: ["green"] }
// 文档C
{ _id: 3, tags: [] }
// 文档D
{ _id: 4 } 执行db.items.find({ tags: { $nin: ["red"] } })时，返回的是文档B、C和D。文档A因为tags中包含red被排除；文档C虽然tags是空数组，但由于没有任何元素等于red，所以被保留；文档D没有tags字段，同样被保留。这一点很关键——字段缺失的文档会被$nin匹配到，如果业务上不希望这种情况发生，需要额外加上{ tags: { $exists: true } }条件。
$nin的等价写法：$not加$in的组合
在聚合管道中，$nin完全等价于{ 字段: { $not: { $in: [...] ] } }的写法。也就是下面两条查询的结果是一样的：
db.users.aggregate([
{ $match: { role: { $nin: ["admin", "root"] } } }
])
db.users.aggregate([
{ $match: { role: { $not: { $in: ["admin", "root"] } } } }
])这种等价关系不只是写法上的差别，它带来两个实际好处。第一，当过滤条件需要动态拼接时，使用$not配合$in更容易在程序代码中构造，特别是在过滤集合可能为空数组的场景下，你可以根据数组长度决定是生成$in条件还是$nin条件。第二，$not还可以与其他操作符组合，比如{ age: { $not: { $gte: 18 } } }，形成了统一的否定式表达风格，代码可读性更好。
需要注意一点，$nin与$ne都表示否定，但它们的粒度不同。$ne后面跟的是单个值，$nin后面跟的是数组。另外两者在数组字段上的行为一致：只要数组里有任意一个元素命中被排除的值，整个文档就会被过滤掉。因此{ tags: { $ne: "red" } }和{ tags: { $nin: ["red"] } }是等价的，当排除列表只有一个元素时，用哪个都可以。
对象数组的嵌套字段处理
实际业务中，数组元素往往是对象而不是简单字符串，比如订单里的商品明细。这时直接对数组字段使用$nin就行不通了，需要通过点号语法定位到嵌套字段：
db.orders.aggregate([
{
$match: {
"items.category": { $nin: ["虚拟商品", "赠品"] }
}
}
])这条语句的语义是：筛选出所有商品明细中，没有任何一件商品属于虚拟商品或赠品的订单。再次强调匹配逻辑——只要items数组中有任意一个元素的category是被排除的值，整个订单就会被过滤。这与部分开发者期望的"只过滤掉那些商品"不同，MongoDB的数组操作永远以文档为单位，不会拆分文档。
如果确实需要更细粒度的控制，比如只保留数组中符合条件的元素而不是过滤整个文档，应该先在管道中使用$unwind把数组展开，再用$match过滤，最后视情况用$group聚合回来。示例：
db.orders.aggregate([
{ $unwind: "$items" },
{ $match: { "items.category": { $nin: ["赠品"] } } },
{
$group: {
_id: "$_id",
items: { $push: "$items" },
total: { $sum: "$items.price" }
}
}
])这种写法会丢弃数组中不符合条件的元素，只保留真正的实体商品参与统计。$match放在$unwind之后还能充分利用索引，如果过滤条件字段上建了索引，尽量把$match提前到管道靠前的位置，这是聚合管道性能优化的基本原则。
常见坑点与性能建议
第一个坑是前面提到的字段缺失问题。$nin会把不包含该字段的文档也算作匹配，这在统计类业务中可能产生脏数据。稳妥的做法是组合条件：
db.products.aggregate([
{
$match: {
color: { $exists: true, $nin: ["white", "black"] }
}
}
])第二个坑是null值。{ field: { $nin: [null] } }这个写法常被用来查询字段存在且不为空的文档，因为字段缺失时其值被视为null，所以它同时排除了字段不存在和字段为null两种情况。但如果字段本身是数组且包含null元素，行为又会叠加数组的匹配规则，使用前建议用小数据集验证一遍结果。
第三个坑是性能。$nin和$ne一样，本质上属于否定条件，无法像正向条件那样高效利用索引，通常会导致全集合扫描。当排除列表非常小而集合数据量很大时，可以考虑反过来思考：先统计总集合，再减去$in命中的部分，或者在设计上增加一个正向的标记字段。另外，$nin的参数数组长度不宜过大，几百个值以内问题不大，成千上万个值时会明显拖慢查询，此时应考虑把业务逻辑改为正向白名单模式。
总结一下，$nin在数组字段上的核心规则是"数组内所有元素都不在给定集合中，且文档包含该字段即可命中"。掌握这条规则，再配合$exists做补强、$unwind做细粒度过滤，就能在聚合管道中准确地控制数据筛选逻辑，避免因误解语义导致的查询结果偏差。
MongoDB聚合管道$nin操作符MongoDB数组查询修改时间：2026-09-07 14:00:37