MongoDB查询与投影实战：从基础语法到性能优化

做后端开发这些年，MongoDB一直是我最常用的文档数据库之一。平时跟同事协作，发现不少人用find()查询时，基本只会往第一个参数里塞条件，第二个参数"投影"要么不写，要么随手填个0、1，结果不是查出大量没用字段，就是莫名其妙报错。这篇就专门聊聊MongoDB的查询条件和投影，把这俩东西彻底说透。

查询条件解决的是"选出哪些文档"的问题，投影解决的是"返回哪些字段"的问题，两者组合起来，才能写出又准又省资源的查询。适合正在学MongoDB的初学者，也适合那些写了不少查询但没系统梳理过语法的后端开发。看完你至少能明白：为什么一个查询条件这么写能命中、那么写就扫全表，以及投影里到底什么时候该用1、什么时候该用0。

1. 查询条件基础：先把find()的底子打牢

1.1 find()到底怎么用

MongoDB里最常见的查询就是find()，它接收三个参数，但日常开发中用得最多的其实是前两个：

javascript复制db.collection.find(query, projection)

第一个参数query是查询条件，第二个参数projection是投影。第三个参数cursor相关的选项（比如skip、limit、sort）一般链式调用就行，不往find()里塞。很多初学者以为find()只能传一个参数，这是个很大的误解。

先给一个最简单的例子。假设有个users集合，里面有这样几条文档：

javascript复制{ "_id": 1, "name": "张三", "age": 25, "city": "北京", "tags": ["后端", "MongoDB"] }
{ "_id": 2, "name": "李四", "age": 30, "city": "上海", "tags": ["前端", "Vue"] }
{ "_id": 3, "name": "王五", "age": 35, "city": "北京", "tags": ["后端", "Java"] }

想查出所有城市在北京的用户，查询条件就是：

javascript复制db.users.find({ "city": "北京" })

这个例子看起来简单，但里面有个关键点：MongoDB的查询条件是"字段名: 值"的JSON结构，字段名要用字符串，值直接写字面量。这跟SQL里的WHERE city = '北京'意思一样，但语法形态完全不同。遇到嵌套字段，就要用点号路径，比如查address.city。这一点在后面的嵌套查询里会专门展开讲。

1.2 比较操作符：不只是等值匹配

等值匹配能解决的场景有限。实际业务里，"年龄大于25"、"价格在100到200之间"、"状态不是已删除"这类范围判断才是大头。MongoDB提供了一组比较操作符，我把它列成了一张速查表：

这里最容易踩的坑是$ne和$nin。很多人以为{ status: { $ne: "deleted" } }就是"选出所有没删除的文档"，但实际上，它还会把status字段不存在的文档也查出来。因为在MongoDB的语义里，字段不存在跟字段值不等于某值，在$ne看来都是"不相等"。如果你只想查status字段存在且值不等于deleted的文档，得写成：

javascript复制db.users.find({
  "status": { $exists: true, $ne: "deleted" }
})

同样是"不等于"，$ne跟SQL里的!=还是有区别的，SQL里NULL比较会返回UNKNOWN，但MongoDB里字段缺失会参与匹配。这种细节文档里写得很含蓄，实际业务里却能让你排查半天。

$in还有一个容易被忽略的用法：它可以跟正则表达式连用。比如查出所有开头的城市是"北"或者包含"州"的城市：

javascript复制db.users.find({
  "city": { $in: [/^北/, /州/] }
})

这样的写法在按多个模糊条件筛选时非常方便，不用手动拼一堆$or。

1.3 逻辑操作符：组合条件的关键

单个字段的查询太简单，真实业务里几乎都是多条件组合。MongoDB有四个逻辑操作符：$and、$or、$nor、$not。很多人以为逻辑条件只能靠$and和$or，其实$nor和$not在某些场景下能大幅简化写法。

先看$or，这是最容易理解的：

javascript复制db.users.find({
  $or: [
    { "city": "北京" },
    { "age": { $gt: 30 } }
  ]
})

这里要特别注意：$or的数组里每一项都是一个完整的条件文档，不是字段名。我见过有人写成{ $or: { "city": "北京", "age": { $gt: 30 } } }，这显然不对。$or的数组结构意味着，每个子条件可以作用在不同字段上。

$and有两种用法。一种是显式使用：

javascript复制db.users.find({
  $and: [
    { "city": "北京" },
    { "age": { $gt: 25 } }
  ]
})

另一种是隐式使用，直接把多个字段条件平铺在同一个文档里。比如{ "city": "北京", "age": { $gt: 25 } }就等同于上面的$and写法。既然平铺写法更简洁，为什么还需要显式的$and？因为当同一个字段需要同时满足多个条件时，平铺写法会出问题。举个例子，你想查age大于20且小于30的文档：

javascript复制// 错误的平铺写法，后面会覆盖前面
db.users.find({ "age": { $gt: 20 }, "age": { $lt: 30 } })

// 正确的显式$and写法
db.users.find({
  $and: [
    { "age": { $gt: 20 } },
    { "age": { $lt: 30 } }
  ]
})

这其实不是MongoDB语法不允许，而是JSON对象本身不允许重复key，后写的会覆盖先写的。所以同一个字段的多条件组合，要么用$and，要么用$gt和$lt合并的形式：{ age: { $gt: 20, $lt: 30 } }。强烈建议用合并形式，更简洁也更快，因为MongoDB在计划执行时不用去解析$and数组。

$nor是"既不满足A也不满足B"：

javascript复制db.users.find({
  $nor: [
    { "city": "北京" },
    { "age": { $lt: 25 } }
  ]
})

等价于：查出所有城市不是北京、且年龄不小于25的文档。注意，$nor同样会匹配字段不存在的文档，这一点跟$ne很像。

$not比较特殊，它是字段级操作符，不能独立使用，必须放在字段条件里。比如查年龄不大于25的：

javascript复制db.users.find({
  "age": { $not: { $gt: 25 } }
})

$not的语义是"取反"，但它跟$ne最大的区别是：$not可以作用于正则表达式、$gt、$lt等比较操作符，而$ne只能做等值取反。比如你想查name不匹配正则/^张/的文档：

javascript复制db.users.find({
  "name": { $not: /^张/ }
})

2. 进阶查询条件：数组、嵌套文档与正则

2.1 数组字段查询：$all、$elemMatch、$size

MongoDB一个很实用的特性就是原生支持数组字段的查询。很多人第一次接触时会下意识把数组查询想复杂，其实核心就几个操作符。

先看一个基本逻辑：查tags包含"后端"这个元素的文档：

javascript复制db.users.find({ "tags": "后端" })

没错，直接写字段名等于某个值，MongoDB会自动匹配数组中是否包含这个值。但这里有个坑：如果你写成{ "tags": ["后端", "MongoDB"] }，那匹配的是整个数组完全等于["后端", "MongoDB"]的文档，而不是"包含这两个元素"。数组内部元素的顺序也很敏感，["MongoDB", "后端"]跟["后端", "MongoDB"]是两回事。

如果想去掉顺序敏感性，用$all：

javascript复制db.users.find({
  "tags": { $all: ["后端", "MongoDB"] }
})

$all的意思是数组必须同时包含这些元素，不管顺序。这在筛选具有多个标签的记录时非常好用，比如说查既懂后端又懂MongoDB的开发者。

再说$size，它精确匹配数组长度：

javascript复制db.users.find({
  "tags": { $size: 3 }
})

$size有一个限制：它不能跟其他条件组合在同一个字段上。比如你想查数组长度大于2的文档，用{ "tags": { $size: 3 } }就行，但想查长度大于2，$size就无能为力了。这时候只能用聚合框架的$expr，或者换个思路：在写入时多维护一个count字段。这也是为什么很多MongoDB高级实践里，会建议在数组频繁被查询的场景下，额外冗余一个数组长度字段。

$elemMatch是在数组元素上应用更复杂的条件。它最典型的场景是：数组里存的是对象，你想匹配对象中某个属性满足条件。举个例子，orders集合里有这样的文档：

javascript复制{ "_id": 1, "items": [ { "name": "鼠标", "price": 50 }, { "name": "键盘", "price": 200 } ] }

想查出items中有一个元素，name是"键盘"且price大于150的订单：

javascript复制db.orders.find({
  "items": { $elemMatch: { "name": "键盘", "price": { $gt: 150 } } }
})

这里的关键是：$elemMatch要求数组里的同一个元素满足所有条件，而不是不同元素分别满足不同条件。如果你不用$elemMatch，写成{ "items.name": "键盘", "items.price": { $gt: 150 } }，那么MongoDB会允许"第一个元素的name匹配了，第二个元素的price匹配了"这种情况，这显然不是你想要的。$elemMatch这个语义细节，是很多线上查询产生脏数据结果的根源。

2.2 嵌套文档查询：点号路径的坑

MongoDB允许字段的值是嵌套的文档对象。比如：

javascript复制{ "_id": 1, "name": "张三", "address": { "city": "北京", "street": "中关村大街" } }

想查address.city为"北京"的文档，常规写法是用点号路径：

javascript复制db.users.find({ "address.city": "北京" })

这条路径的语法很简单，但有一个常见的坑：如果某个文档的address字段是null，或者压根没写address，{ "address.city": "北京" }是查不出这些文档的，这在语义上符合预期，但很多人会误以为"城市不是北京的文档都能查出来"，其实字段不存在的文档根本不会出现在结果里，如果你还叠加了$ne条件，那坑就更大了。

嵌套文档还有一种整块匹配的写法：

javascript复制db.users.find({ "address": { "city": "北京", "street": "中关村大街" } })

这种方式要求嵌套文档的字段值完全一致，包括字段顺序。{ "street": "中关村大街", "city": "北京" }不会被匹配到。所以实际开发中，我几乎不用整块匹配，一律推荐点号路径。

如果嵌套文档里还有数组，点号路径同样适用。比如：

javascript复制{ "_id": 1, "orders": [ { "id": "A1", "amount": 100 }, { "id": "B2", "amount": 200 } ] }

想查orders数组中存在id为A1的文档：

javascript复制db.users.find({ "orders.id": "A1" })

注意，这时返回的是整个文档，而不是只返回匹配的那个orders元素。想只返回匹配的数组元素，就需要用到投影里的$elemMatch，这个后面会讲到。

2.3 正则与模糊匹配

MongoDB的正则查询是很多人喜欢它的原因之一，因为写法太灵活了。直接在条件里写正则即可：

javascript复制// 查name以"张"开头的
db.users.find({ "name": /^张/ })

// 等价写法
db.users.find({ "name": { $regex: "^张" } })

正则查询支持在字段值上做模式匹配，也支持不区分大小写等选项。比如想查所有包含"mongo"的标签，不区分大小写：

javascript复制db.users.find({ "tags": { $regex: "mongo", $options: "i" } })

$options的可选值有i（忽略大小写）、m（多行匹配）、s（让.匹配换行符）、x（忽略空白）。日常开发里i和m用得最多。

但正则查询有个性能大坑：如果正则没有锚定开头（比如不是以^开头），那么MongoDB无法使用普通索引来加速查询，只能做全集合扫描。这一点在数据量大的集合上特别明显。建议使用这种方式之前，先评估一下查询的返回量级和频率。如果只是为了模糊搜索，数据量又大，倒不如考虑引入专门的全文搜索引擎或者用文本索引。

再补充一个实用的组合：正则和$in配合。上面的1.2节提过，这里举个实际例子。假设你想查所有名字以"张"或者"李"开头的用户：

javascript复制db.users.find({
  "name": { $in: [/^张/, /^李/] }
})

这种写法比用$or拼正则要简洁很多，执行计划也会更优。

3. 投影：管住返回字段，才能省心

3.1 包含与排除两种模式

查询条件决定了返回哪些文档，投影决定了这些文档里返回哪些字段。很多人觉得投影不就是把不需要的字段设为0吗？其实没有那么简单。

投影有两种模式：包含模式（字段值设为1）和排除模式（字段值设为0）。下面这个查询，只返回name和age字段：

javascript复制db.users.find({}, { "name": 1, "age": 1 })

返回结果：

javascript复制{ "_id": 1, "name": "张三", "age": 25 }

注意_id字段默认就会被返回，即使你没在投影里写它。不想返回_id，必须显式排除：

javascript复制db.users.find({}, { "name": 1, "age": 1, "_id": 0 })

包含和排除能不能混用？这有一个明确的规则：除了_id，其他字段不能在同一个投影里同时出现1和0。也就是说，{ "name": 1, "age": 0 }是非法的，会直接报错。这是因为MongoDB想让执行计划更清晰：要么只选一部分字段，要么排除一部分字段，混用容易产生歧义。唯一的例外是_id，你可以在包含模式下排除_id，也可以在排除模式下包含_id。

什么时候用包含模式，什么时候用排除模式？我的经验是：

• 文档里字段很多，只需要少数几个字段时，用包含模式，既能省流量，又让返回结构更干净。
• 文档里字段不多，但有几个大字段（比如Log内容、大文本描述）不想返回时，用排除模式，比如把content字段排除掉。
• 如果字段特别多，又只需要排除一两个，用排除模式更少写代码。

两种模式没有绝对优劣，按场景来就行。

3.2 数组与嵌套字段的投影

投影也支持嵌套字段和数组。先看嵌套字段，假设文档里有address.city和address.street：

javascript复制db.users.find(
  { "address.city": "北京" },
  { "address.city": 1, "_id": 0 }
)

这样返回时，address字段里只会保留city，不会返回street。这可以帮你省掉不少不必要的字段传输。

数组字段的投影稍微复杂一点。默认情况下，返回整个数组。如果只想返回数组的前几个元素，可以用$slice：

javascript复制// 返回tags数组的前2个元素
db.users.find({}, { "name": 1, "tags": { $slice: 2 } })

// 跳过前1个，返回后面的2个
db.users.find({}, { "name": 1, "tags": { $slice: [1, 2] } })

$slice的数组形式是[skip, limit]，这个在分页场景特别有用，比如文章列表只需要返回每篇文章的前3条评论。

如果数组元素是对象，用$elemMatch投影可以只返回第一个匹配条件的数组元素：

javascript复制db.orders.find(
  { "items.name": "键盘" },
  { "items": { $elemMatch: { "name": "键盘" } } }
)

注意，$elemMatch投影在MongoDB 4.4之前，只返回第一个匹配元素；4.4之后增加了一个$elemMatch的聚合阶段支持返回多个匹配，但find()的投影仍然只返回第一个。这个细节在生产环境容易引发误解，返回值跟你预期不一样，不是代码写错了，而是API设计的限制。

$slice和$elemMatch都是数组投影中比较特殊的操作符，它们不跟1、0混用，语法上是数组字段的值形式。其实这也符合投影的定位：你想让返回的数组从"全量"变成"部分"。

3.3 投影和查询条件的配合

投影虽然写在第二个参数，但它跟查询条件在同一个find()里，有时会给人错觉，以为投影能影响匹配结果。实际上投影永远不影响查询条件，它只影响返回字段。这个原则一定要记住。

一个常见的误区是：有人想"根据某个数组元素匹配成功，只返回这个元素"，于是在查询条件里写了数组字段的匹配，又在投影里用了$elemMatch，结果发现返回的数据是对的，就以为两个条件联动了。其实查询条件负责筛选，投影负责裁剪，两者各司其职。如果查询条件匹配了某个文档，但该文档的数组中并没有符合投影$elemMatch条件的元素，那么返回结果中，该数组字段会是空数组，而不是整个文档被过滤掉。

处理这种需求时，正确的思路是：先用查询条件把文档筛选出来，再用投影把数组元素裁剪到最小范围。如果你需要的是"数组中匹配的元素"之外的其他字段，也可以把投影放宽，比如用聚合框架的$filter，一次性把数组过滤和字段裁剪都做了。聚合框架在这块比find()更灵活，尤其是MongoDB 4.2之后新增的$filter配合$project，能处理很多find()投影做不到的逻辑。

另一个容易忽略的点：投影如果只包含一个嵌套字段，比如"address.city": 1，返回的结果是address对象里只有city。这实际上改变了数据结构的层级，可能影响下游代码。比如下游用了user.address.street，那就会读到undefined。所以在投影嵌套字段时，一定要提前跟消费方对齐数据结构。

4. 实操中的查询性能与索引

4.1 explain()：看清查询执行计划

写了再多查询，最终还是要跑在生产数据上。数据量一大，索引和查询计划的差异就非常明显。MongoDB提供了explain()方法，可以查看一个查询的执行计划。用法很简单：

javascript复制db.users.find({ "city": "北京" }).explain("executionStats")

返回的内容很多，我建议重点看这几项：

最核心的观察点就是：是COLLSCAN（全集合扫描）还是IXSCAN（索引扫描）。如果totalDocsExamined远大于nReturned，说明查询条件没有充分利用索引，正在做低效的过滤。

比如在users集合上没建城市索引，执行：

javascript复制db.users.find({ "city": "北京" }).explain("executionStats")

winningPlan.stage很可能是COLLSCAN，totalDocsExamined等于集合总数，nReturned只有几十条。这时候就该建索引了。建完索引再跑一次，stage会变成IXSCAN，totalKeysExamined和nReturned基本一致，性能提升非常直观。

explain()还有两个常见模式：queryPlanner和allPlansExecution。queryPlanner返回的是计划选择阶段的概览，不执行具体查询；allPlansExecution会执行所有候选计划，返回更准确的执行统计。调优时先看queryPlanner，再视情况用executionStats，别一上来就跑allPlansExecution，那个开销更大。

4.2 索引对查询条件的影响

索引的选择直接影响上面explain()里的stage。MongoDB支持单字段索引、复合索引、多键索引（数组字段索引）、文本索引、地理空间索引等。对应到查询条件上，最常见的优化就是给高频查询字段建单字段索引：

javascript复制db.users.createIndex({ "city": 1 })

如果是复合查询，比如经常同时按city和age过滤，那就建复合索引：

javascript复制db.users.createIndex({ "city": 1, "age": 1 })

复合索引的字段顺序很关键。{ city: 1, age: -1 }和{ city: 1, age: 1 }对查询来说通常都能覆盖(city, age)的条件，但如果你经常只用age做过滤，复合索引就帮不上忙，因为age不是最左前缀。这个跟MySQL的联合索引原理一样，MongoDB同样遵循最左前缀规则。

对于正则查询，如果正则不是以^开头，索引一般不生效。这一点我在2.3节提过。如果业务里一定要用这种模糊查询，可以考虑引入独立的搜索引擎方案；如果量不大，也可以用MongoDB的文本索引配合$text查询，但文本索引对中文分词的支持有限，需要根据实际情况评估。

数组字段的索引是多键索引，MongoDB会自动为数组字段创建多键索引。但多键索引有一个限制：一个文档中不能有多个数组字段被同一个复合索引覆盖。举个例子，在一个索引里同时包含"tags": 1和"comments": 1，如果某条文档里tags和comments都是数组，MongoDB会报错，因为多键索引不能嵌套多个数组路径。这个限制比较冷门，但遇到了会让人一头雾水。

4.3 慢查询与排查思路

慢查询是MongoDB实践里绕不开的话题。排查慢查询，第一步是开启慢查询日志。MongoDB默认会把超过100ms的查询记录到日志里，相关的阈值可以通过setParameter修改：

javascript复制db.adminCommand({
  "setParameter": 1,
  "slowMS": 200
})

然后可以通过查看system.profile集合，或者直接看进程日志，找到执行时间长的查询。把慢查询的语句拿出来，先跑一遍explain()，重点看totalDocsExamined和nReturned的比值。比值越大，说明过滤效率越差。

接着检查查询条件里涉及的字段有没有索引。如果没索引，先建索引再看。如果有了索引还很慢，要看是不是索引选择不合适，比如复合索引字段顺序反了、正则没法走索引、或者用了$where这种无法利用索引的写法。

$where是另一个容易让人踩坑的地方。它允许写JavaScript表达式做过滤，但MongoDB在执行$where时无法使用索引，只能全集合扫描。所以线上环境我基本不用$where，宁可用聚合框架的$expr配合普通字段条件，至少还能部分利用索引。

如果你发现某个查询经常被触发，且返回的数据基本固定，可以考虑用覆盖索引（Covered Query）。当查询条件里用到的字段和投影里需要的字段都在同一个索引里时，MongoDB可以直接从索引返回数据，不需要回表FETCH。比如：

javascript复制db.users.createIndex({ "city": 1, "name": 1 })
db.users.find(
  { "city": "北京" },
  { "name": 1, "_id": 0 }
).explain("executionStats")

如果计划里出现IXSCAN之后直接没有FETCH，或者FETCH的docsExamined是0，就说明命中覆盖索引了。这种查询性能极好，但要注意投影里不能包含索引之外的字段，就连_id也得显式排除。

5. 常见问题与避坑实录

5.1 高频报错与原因速查

我在实际使用和帮别人排查时，遇到最多的问题集中在以下几类。整理成一张速查表，方便直接对照：

5.2 我踩过的几个坑与教训

第一个坑，是$ne和字段不存在的语义问题。有一次我统计未删除用户列表，写了{ "status": { $ne: "deleted" } }，结果把大量没有status字段的旧数据也查出来了，导致数量统计严重偏高。后来我改成：

javascript复制db.users.find({
  "status": { $exists: true, $ne: "deleted" }
})

数据才恢复正常。这个坑的核心在于，MongoDB对字段缺失的处理逻辑跟SQL不一样，它不会把字段缺失当作NULL，而是当作"不满足条件"和"满足条件"之外的第三种状态。尤其在$ne、$nin、$nor这些取反操作符里，字段缺失的文档一定会被匹配到。要始终记住这条规则。

第二个坑，是嵌套文档整块匹配时，字段顺序必须一致。之前有一个同步脚本，上游数据里的address字段顺序跟我们库里存的顺序不同，导致查询结果"莫名其妙"变少了。排查了很久才发现是整块匹配的问题。后来我全部改成点号路径，彻底规避。

第三个坑，是投影中的嵌套字段导致下游数据结构变化。我在一个项目里做了投影{ "address.city": 1, "_id": 0 }，下游代码直接用address.city，但因为address.street没有返回，导致整个address对象里只剩下city，一些用street的代码直接报错。从那以后，我每次做嵌套字段投影，都会跟下游对接人确认数据结构，或者在代码里做好字段缺失的兜底。

第四个坑，是聚合框架里的$match写法和find()的查询条件很相似，但有一个细微差异：$match里不能用$where，而且$match的字段路径如果包含数组下标，比如"items.0.name"，在find()里是有效的，在$match里同样有效，但很多人不熟悉这种写法。其实查询条件这块，find()和aggregate的$match规则基本一致，只是$match还能用$expr等更灵活的表达式。所以如果你发现某个查询在find()里写不出来，去$match里找找答案，可能会有惊喜。

第五个坑，是explain()的结果很容易让人误判。有时候totalDocsExamined很小，但totalKeysExamined很大，说明索引扫描了很多键才过滤出少量文档。这种情况通常是索引字段的顺序不合适，比如索引是{ city: 1, age: 1 }，但查询只用了age做条件。索引覆盖不了查询，就会全量扫索引键。建复合索引前，一定要先梳理业务里的高频查询模式，用explain()验证。

5.3 几个实用的小技巧

最后分享几个我在实操中积累的小技巧，不算高深，但很管用。

第一，查询字段值里如果有多选下拉这种场景，千万别用多个$or拼，直接:

javascript复制db.users.find({ "city": { $in: ["北京", "上海", "广州"] } })

第二，想限制返回条数时，别用find()的第三个参数，直接链式调用limit：

javascript复制db.users.find({ "city": "北京" }).limit(20).skip(0)

limit和skip的组合能实现简单的分页。但数据量很大时，skip+limit的性能会越来越差，因为MongoDB必须先扫描并丢弃前面skip条记录。更推荐的做法是用排序字段加范围条件做游标分页。比如按_id排序：

javascript复制db.users.find({ "_id": { $gt: lastId } }).limit(20).sort({ "_id": 1 })

这样的分页在深翻页时性能稳定得多。

第三，当查询条件里既要对多个字段做范围判断，又要处理数组元素匹配时，把条件按"索引友好程度"排个序：等值条件放最前，范围条件次之，数组和正则最后。这样写不是为了语法好看，而是为了让MongoDB在选择索引时更高效。等值条件通常能直接定位到索引键，范围条件会扩大扫描范围，数组字段和正则往往无法有效利用索引，放在后面不会干扰前面的精确匹配。

第四，写查询时，如果条件里只关心某个字段是否存在，用$exists比用$ne + null更直观：

javascript复制// 查有address字段的用户
db.users.find({ "address": { $exists: true } })

// 查没有phone字段的用户
db.users.find({ "phone": { $exists: false } })

注意，这种写法对address字段值为null的情况依然会返回true，因为字段是存在的，只是值为null。如果想排除null值，还是要叠加$ne: null。

第五，条件里字段名如果包含特殊字符，比如点号或者$，用普通的点号路径写会有歧义。MongoDB 5.0之后可以用引号包裹字段名，但一般不建议在字段名里使用这些特殊字符。如果历史数据里真有这样的字段名，查询时要注意转义或使用聚合框架里的$getField。

结尾

写到这里，MongoDB的查询条件和投影基本就聊得比较透了。我在实际项目里，几乎每天都要跟find()、聚合框架、explain()打交道，最大的感受是：MongoDB的查询语法表面上很灵活，但每个写法的背后都有明确的语义边界，比如$ne会匹配字段缺失的文档、投影的包含和排除不能混用、数组查询要区分"包含"和"整个等于"、$elemMatch针对的是同一个数组元素。理解这些边界，比背一堆操作符示例更有价值。如果你在写查询时遇到结果不符合预期，先别急着怀疑数据，回到这些基础语义上检查一遍，往往很快就能找到原因。