先说一个让不少开发者都感到困扰的问题：在 MongoDB 中执行“不等于”筛选时，你是不是第一反应就写成 {$ne: "value"}？

$ne 确实是 MongoDB 里最直观的“不等于”查询操作符，它会匹配字段值不等于指定值的文档——注意，这里的不等于，还包括字段缺失或字段值为 null 的文档。听起来很方便？但实际使用过程中，很容易踩坑。类型隐式转换、null 和缺失字段的处理逻辑、索引失效……这些问题常常导致结果与预期不符。所以，先别急着写 $ne，先了解一下下面这几个关键点。

为什么 $ne 有时查不到“明明不等于”的文档？

MongoDB 的 $ne 有一个设计行为：它不仅会排除匹配值，还会包含字段不存在或字段值为 null 的文档。举个例子：

db.users.find({ status: { $ne: "active" } })

这条查询会返回 status: "inactive" 的文档，也会返回 status: null 的文档，甚至还会返回一个根本没有 status 字段的空文档 {}。这不是 bug，这就是设计。

• 如果你只想排除 "active"，同时要求 status 字段必须存在且不为 null，那就得换种写法：用 $not + $eq，再显式检查字段存在性：{ status: { $exists: true, $ne: "active" } }
• 如果字段类型混杂（比如字符串和数字并存），$ne: "1" 是不会匹配 { status: 1 } 的。因为 MongoDB 采用严格类型比较，"1" !== 1。
• 对数组字段使用 $ne 时，它比较的是整个数组是否“不等于”某个值，而不是“数组中所有元素都不等于”某个值。这个区别至关重要。

什么时候该用 $not + $eq 而不是 $ne？

这两个组合的语义几乎等价，但 $not 更灵活，尤其在需要配合其他操作符时，优势就体现出来了：

• $ne 不能用于嵌套查询或组合条件。比如 { $ne: { $gt: 10 } } 是非法语法。而 $not: { $eq: ... } 或 $not: { $in: [...] } 是合法表达式。
• 当你要否定一个复合条件（例如“不是 status=active 且 age > 18”这样的组合），只能用 $not: { $and: [...] }，$ne 不支持这种复杂度。
• 在索引使用上，多数情况下 $ne 无法高效利用索引（MongoDB 往往会退化为全表扫描）。而 $not: { $eq: ... } 在某些版本中可能触发索引优化——当然，这还需实际测试验证。

对数组字段做“不包含某值”筛选，别误用 $ne

这一点特别容易翻车。$ne 作用于数组字段时，比较的是整个数组的值。举例来说：

db.posts.find({ tags: { $ne: ["mongodb", "nodejs"] } })

上面这条查询只会排除那些 恰好等于 ["mongodb", "nodejs"] 的文档。它不会排除 ["mongodb", "python"]，也不会排除 ["mongodb"]。

那如果真想表达“tags 数组中不包含 "python"”呢？注意以下都是常见陷阱：

• { tags: { $ne: "python" } } —— 错！这是把数组和字符串比较，类型不同，永远为真。
• { tags: { $not: { $eq: "python" } } } —— 同样错误，逻辑不通。
• ✅ 正确的写法是：{ tags: { $not: { $elemMatch: { $eq: "python" } } } }。或者更简洁（但不推荐，因为依赖点号路径）：{ "tags.python": { $exists: false } }。
• 另一个常用且清晰的思路：{ tags: { $all: ["python"] } } 取反，改用 $nor，或者走聚合管道用 $filter 处理。

总而言之，$ne 的边界行为比表面看起来复杂得多。它对 undefined 的处理已经弃用，在分片集群中可能引发查询不一致，与 $regex 组合时语法也受限。真要稳妥地做“不等于”筛选，优先考虑 $in 列出允许值，或者在聚合阶段用 $cond 显式控制逻辑——这样心里才踏实。