企业官网建设流程全解析

1. 写在前面：为什么数组和嵌套文档是MongoDB躲不开的课题

接触MongoDB的人基本都会遇到同样的情况：一开始用得很顺手，存一条普通的JSON文档，查询也就是db.collection.find({field: value})，简单直接。但业务一复杂，数据里出现数组、出现对象嵌套对象之后，查询就变得不再那么“直觉”了。比如一个订单里有多个商品，每个商品有名称、价格、数量；或者一个用户有多个地址，每个地址有省市区。这些场景如果继续用关系型数据库的思路去设计表结构，会非常别扭，而MongoDB天生支持数组和嵌套文档，这既是它灵活性的来源，也是新手最容易踩坑的地方。

这个文档里没有统一的表结构约束，数组里面既可以存基本类型，也可以存子文档，还可以用$elemMatch这类专门为数组设计的操作符做精细匹配。但很多人一上来就按照普通字段的写法去查，比如直接{arrayField: {name: "xxx"}}，结果要么查到错误结果，要么根本不返回。

这篇文章想解决的问题很直接：数组怎么匹配、嵌套对象怎么查、$elemMatch什么时候用、什么时候不能用、以及配合更新和索引时有哪些容易忽略的细节。我会结合实际业务中经常遇到的需求，把查询逻辑拆开讲清楚，尽量让每个例子都能直接跑起来，落到自己的项目里。

适合谁看？正在写MongoDB查询但结果总是不对的人，刚把数据模型从关系型迁移到文档型的设计人员，以及想系统梳理数组和嵌套文档操作方法、准备做性能优化的开发者。当然，如果你只是临时查一下数据，里面的语法案例也能直接抄。

2. 数据模型设计：数组和嵌套文档到底解决了什么问题

2.1 什么时候该用嵌套文档，什么时候不该用

MongoDB的文档模型鼓励把相关联的数据放在一起。一个典型的例子是博客系统的评论，如果一张文章表里要展示最新的几条评论，用嵌套数组存评论，查询文章时一次就能把评论带出来，不需要额外的关联查询。另一个常见场景是电商订单，订单地址、商品明细、支付信息都可以作为嵌套结构存在订单文档里，这是非常自然的设计。

但并不意味着所有数据都适合嵌套。如果嵌套数组无限增长，比如一个商品下面有几十万条评价，全塞进商品文档里，文档会越来越大，每次读写都要传输全量数据，性能会直线下降。这种情况下更适合把评价单独建集合，通过某种外键关联。所以在设计阶段就要考虑数据增长的规模和数据访问的模式。

嵌套文档的核心优势是局部性（locality）：相关数据存一起，一次IO全部读取。这在很多业务里非常划算，代价是更新时可能需要操作大文档。数组操作尤其是$push和$pull，如果数组特别大，也会有性能问题。我的经验是：一对多关系中，如果“多”的数量可控（比如几十到几百条），优先嵌入；如果数量不可控，优先引用。

2.2 数组里存什么：标量数组还是对象数组

数组元素可以是字符串、数字、日期等标量，也可以是子文档。这两种结构在查询语法上差异很大。标量数组的匹配逻辑偏“集合包含”的思路，比如标签列表、评分历史；对象数组的匹配则要小心“整个子文档精确匹配”和“子文档字段匹配”的区别。

举例来说：

// 标量数组 {"tags": ["mongodb", "database", "nosql"]} // 对象数组 {"items": [ {"name": "apple", "price": 5, "qty": 2}, {"name": "banana", "price": 3, "qty": 5} ]}

查询标量数组可以用{tags: "mongodb"}，MongoDB会判断目标值是否在数组中。查询对象数组时，如果你用{items: {name: "apple", price: 5, qty: 2}}，它要求的是数组中存在一个与这个子文档完全相等的元素，字段顺序和值都必须一致。如果只是查“是否有名叫apple的商品”，你需要{items.name: "apple"}，这种点路径写法会在每个数组元素的对应字段上做匹配。

这一层看起来简单，但很多人一开始容易混，导致后续查询写出与自己意图完全相反的条件。

3. 数组匹配的核心操作：从包含到多条件组合

3.1 单元素匹配与$in的用法

最简单的场景：查所有带“mongodb”标签的文章。

db.articles.find({tags: "mongodb"})

这条查询会扫描tags数组，如果数组中的任意一个元素等于目标值，文档就匹配。这个行为等价于关系型数据库里的“多对多关系关联表存在该值”，但写起来完全不用join。

如果要匹配多个标签中的任意一个，可以用$in：

db.articles.find({tags: {$in: ["mongodb", "database"]}})

这里要特别注意，$in是“数组元素命中其中之一”就返回文档。如果你要的是同时包含两个标签，那就不能写$in，应该写成：

db.articles.find({tags: {$all: ["mongodb", "database"]}})

$all的含义是数组必须包含所有指定值。很多从SQL转过来的人容易把$all和$in搞反。我在实际项目里就踩过这个坑：统计同时满足多个条件的用户时，写成了$in，导致结果多了一大截。

3.2 数组多条件匹配的两个层级

当数组元素是标量时，{tags: {$in: [...]}}和{tags: {$all: [...]}}已经能覆盖大部分需求。但当数组元素是对象时，问题就复杂了。

假设一个订单集合里，items是商品对象数组：

db.orders.insertOne({ orderNo: "123", items: [ {name: "apple", price: 5, qty: 2}, {name: "banana", price: 3, qty: 5} ] })

现在要查“订单中包含名为apple且数量为2的商品”。很多人会试着写：

db.orders.find({items: {name: "apple", price: 5, qty: 2}})

这个写法只有在数组里存在一个完全等于{name: "apple", price: 5, qty: 2}的子文档时才匹配。如果price字段的值顺序不同，或者子文档里多了个字段，就不会匹配。这种方式叫整个子文档的精确匹配，可用但非常脆弱。

更常见的是按字段匹配：

db.orders.find({"items.name": "apple", "items.qty": 2})

这条查询的含义是：数组中存在某个元素的name等于 "apple"，数组中存在某个元素（不一定是同一个）的qty等于 2。也就是说，它不要求“同一个商品元素同时满足两个条件”。如果订单A包含一个叫apple的商品（qty=1），又包含一个叫pear的商品（qty=2），那么{"items.name": "apple", "items.qty": 2}也能查出来，因为name和qty分别可以在不同元素上命中。

这跟直觉“我在同一个子文档上加了两个条件”是不同的逻辑。想表达“同一个数组元素同时满足多个字段条件”时，就需要$elemMatch。

3.3$elemMatch的正确姿势

$elemMatch的官方定位是：匹配数组中至少一个元素满足所有指定条件。

db.orders.find({ items: { $elemMatch: { name: "apple", qty: 2 } } })

这个查询只会返回那些包含某个商品，且这个商品的name是apple、qty是2的订单。它把多个字段条件都限制在同一个数组元素上，行为符合业务直觉。

$elemMatch也适用于标量数组的元素多条件，不过标量数组用$in或$all更简洁。对象数组里，$elemMatch几乎是标配。还有一个容易忽略的细节：$elemMatch里还可以组合比较操作符，比如：

db.orders.find({ items: { $elemMatch: { name: "apple", price: { $gte: 4, $lte: 6 } } } })

这样能精确描述“存在一个名为apple且价格在4到6之间的商品”。

需要注意，$elemMatch也可以作为顶层操作符，用于对数组字段做整体匹配，比如：

db.orders.find({ items: { $elemMatch: { name: {$in: ["apple", "banana"]}, qty: {$gt: 3} } } })

这种情况下，$elemMatch是在items数组的维度上工作，同样要求同一个数组元素同时满足两个条件。

我把这个差异总结成一个判断方法：如果查询条件里的多个字段都来自同一个数组，而且你希望它们作用于同一个数组元素，用$elemMatch；如果只是针对文档的多个独立字段，用常规的点路径并列条件。

4. 嵌套对象查询：点路径与子文档匹配的区别

4.1 嵌套对象中的点路径查询

对象嵌套在外面一层时，查询也会用到点路径。比如用户档案里有一个address子对象：

db.users.insertOne({ name: "张三", address: { city: "北京", district: "海淀区" } })

查询海淀区的用户：

db.users.find({"address.district": "海淀区"})

这里的点路径实际上就是在扁平化字段名，MongoDB把address.district当成一个独立的索引字段对待。这个查询结构清晰，性能也依赖索引。

如果嵌套层级更深，比如：

{ "address": { "geo": { "lng": 116.2, "lat": 39.9 } } }

查询{"address.geo.lat": 39.9}完全没问题。点路径可以持续延伸，没有层级限制（只要不超过文档字段名长度限制）。

4.2 嵌套对象精确匹配的坑

有时你会看到有人这样写：

db.users.find({address: {city: "北京", district: "海淀区"}})

这种查询要求address字段的值完全等于传入的子文档，字段顺序必须一致，不能多字段不能少字段。实际业务里很少能保证这种一致性，所以不建议在这种场景下使用整个子文档匹配。除非你存储时本来就固定了字段顺序和结构，并且想利用复合索引字段顺序来查询，否则还是老老实实用点路径。

需要特别注意的是，当字段值本身是数组时，点路径会动用数组匹配逻辑：

{ "addresses": [ {"city": "北京", "district": "海淀区"}, {"city": "上海", "district": "浦东新区"} ] }

查询{"addresses.city": "北京"}会返回这个用户，因为数组中存在一个元素的city等于北京。这种查询同样存在“不同元素字段交叉命中”的问题，想要更严格的语义，照样要$elemMatch。

4.3 查询子文档中不存在的字段

有时候需要排查数据质量问题，比如想找出没有填写district的用户：

db.users.find({"address.district": {$exists: false}})

注意，如果address字段本身不存在，或address是null，$exists: false也会匹配到。如果你只想筛“有address对象但没有district字段”的情况，还需要加一下地址本身非空的条件，这在实际数据清洗时很容易遗漏。

对于嵌套数组，如果要查“items中没有任何商品价格超过100”的订单，可以配合$not和$elemMatch：

db.orders.find({ items: { $not: { $elemMatch: { price: { $gt: 100 } } } } })

这种写法语义上表示“不存在任何一个满足条件的元素”，是取反逻辑的典型用法。

5. 数组与嵌套的更新操作：查询之后还得改数据

5.1$push、$pull与数组元素的操作习惯

查询只是第一步，业务里更常见的是对数组做增删改。比如向订单中追加商品：

db.orders.updateOne( {orderNo: "123"}, {$push: {items: {name: "orange", price: 4, qty: 3}}} )

从数组中移除指定商品，通常需要精确指定子文档：

db.orders.updateOne( {orderNo: "123"}, {$pull: {items: {name: "orange"}}} )

$pull用条件匹配，不要求完全相等的子文档，只要数组中某个元素满足条件就会移除。这个操作非常实用，比如批量清理价格过高的商品：

db.orders.updateOne( {orderNo: "123"}, {$pull: {items: {price: {$gt: 10}}}} )

需要注意，$pull中如果写的是对象，比如{$pull: {items: {name: "apple", price: 5}}}，它匹配的是数组中“满足所有字段条件”的单个元素，而不是完全相等的整个子文档。这个行为跟查询时的$elemMatch语义类似，但写法上不需要显式写$elemMatch，MongoDB会自动做元素级字段匹配。因此如果你真的想完全精确匹配整个子文档，反而不太容易用$pull直接实现，通常还是用一个唯一标识字段来定位。

5.2 更新嵌套数组中的特定元素

更新嵌套数组里“某个符合条件的元素”是MongoDB早期版本的一大痛点。假设要把订单中name为apple的商品价格改成6，很多人第一反应是：

db.orders.updateOne( {orderNo: "123", "items.name": "apple"}, {$set: {"items.price": 6}} )

这种写法会把数组里所有满足条件的元素的price都改成6，因为点路径在数组上会匹配所有命中元素。如果你只想改第一个命中的元素，MongoDB 3.6之后引入的$[identifier]过滤器（位置操作符）可以做到：

db.orders.updateOne( {orderNo: "123", "items.name": "apple"}, {$set: {"items.$[elem].price": 6}}, {arrayFilters: [{"elem.name": "apple"}]} )

这里arrayFilters定义了elem这个过滤器，只更新满足条件的数组元素。这个特性极大增强了嵌套数组的可操作性，尤其适合“订单里同一种商品有多条记录但只想改其中某一条”的场景。

如果你是MongoDB 5.0及以上，还可以使用更直观的$setKey或一些聚合管道更新，但arrayFilters依然是兼容性最好、使用最广的方案。老版本甚至可以用$占位符更新数组中第一个匹配元素：

db.orders.updateOne( {"items.name": "apple"}, {$set: {"items.$.price": 6}} )

$更新的是匹配到的数组中第一个元素，这种写法简单但只更新一个。如果业务上需要更新的恰好就是第一个，它可以胜任。但一旦过滤条件变复杂，$就不好写了，此时优先arrayFilters。

5.3 去重与聚合：数组操作的高级版

数组去重用$addToSet，它和$push的区别是如果目标值已存在就不会重复加入：

db.users.updateOne( {name: "张三"}, {$addToSet: {tags: "mongodb"}} )

如果 tags 中已经有 "mongodb"，这个操作不会产生变化。对于对象数组，只要子文档完全相等，就不会重复添加。如果允许重复，用$push；不允许重复，用$addToSet。这个选择往往决定了数据质量，我见过的不少脏数据就是$push用得太随意导致的。

另外，聚合管道的$unwind是查询数组数据时的神兵利器。把数组展开成多行之后，再和普通文档一样聚合：

db.orders.aggregate([ {$unwind: "$items"}, {$group: {_id: "$items.name", totalQty: {$sum: "$items.qty"}}} ])

这条管道能算出每个商品在所有订单中的总数量。$unwind需要处理空数组的清洗问题，可以用{preserveNullAndEmptyArrays: true}保留空数组订单。这个细节如果忽略，聚合结果会莫名少掉很多文档。

6. 实操案例：模拟一个带商品明细的订单系统

6.1 案例需求与数据准备

为了把上面的理论串起来，我用一个接近真实的模拟场景来演示。假设我们在做一个电商后台，订单集合结构如下：

db.orders.insertMany([ { orderNo: "ORD001", customer: "张三", status: "paid", items: [ {sku: "sku_apple", name: "苹果", price: 5, qty: 2}, {sku: "sku_banana", name: "香蕉", price: 3, qty: 5} ], payment: {method: "wechat", amount: 25} }, { orderNo: "ORD002", customer: "李四", status: "unpaid", items: [ {sku: "sku_apple", name: "苹果", price: 5, qty: 1}, {sku: "sku_pear", name: "梨", price: 4, qty: 3} ], payment: {method: "alipay", amount: 17} }, { orderNo: "ORD003", customer: "王五", status: "paid", items: [ {sku: "sku_mango", name: "芒果", price: 8, qty: 2} ], payment: {method: "bank", amount: 16} } ])

需求清单：

1. 查找购买了苹果的订单。
2. 查找同时买了苹果和香蕉的订单。
3. 查找“购买苹果且数量大于1”的订单。
4. 查找支付方式为微信且总金额大于20的订单。
5. 查找没有任何商品价格高于6元的订单。

6.2 查询需求逐个实现

第一个需求很简单，直接{"items.name": "苹果"}即可，返回ORD001和ORD002。

第二个需求，同时包含两个商品，必须用$all：

db.orders.find({"items.name": {$all: ["苹果", "香蕉"]}})

这里返回ORD001。注意$all用在了字段items.name上，它的语义是：数组中所有元素的name里，既要出现"苹果"，又要出现"香蕉"。数组元素可以是不同商品，符合需求。

第三个需求，同一商品必须同时满足名称和数量条件：

db.orders.find({ items: { $elemMatch: { name: "苹果", qty: {$gt: 1} } } })

返回ORD001。ORD002虽然也叫苹果，但qty是1，所以被排除。这里如果用并列点路径{"items.name": "苹果", "items.qty": {$gt: 1}}，ORD002也会被查出来，因为它的items里有qty为3的梨，这个qty大于1也能命中。这种错误非常隐蔽，我看到不少生产事故的根因就在这里。

第四个需求，支付金额和方式都在嵌套对象里，直接用点路径：

db.orders.find({ "payment.method": "wechat", "payment.amount": {$gt: 20} })

返回ORD001。因为这两个条件都作用在同一个payment对象上，而payment不是数组，所以常规点路径并列条件是准确的，不需要$elemMatch。换句话说，$elemMatch只在数组元素维度才有意义。

第五个需求，没有任何商品价格高于6元，用$not配合$elemMatch：

db.orders.find({ items: { $not: { $elemMatch: { price: { $gt: 6 } } } } })

ORD001里最高价是5，ORD002最高价是5，都符合；ORD003有8元芒果，被排除。结果是前两个订单。这种查询在运营筛选时很常用，比如筛选“没有高价商品”的活动范围。

6.3 更新需求实操

继续丰富这个案例，假设运营想对ORD002进行改价：

• 把苹果价格从5改成6；
• 只改苹果这一项，不影响梨。

arrayFilters写法：

db.orders.updateOne( {orderNo: "ORD002"}, {$set: {"items.$[item].price": 6}}, {arrayFilters: [{"item.sku": "sku_apple"}]} )

执行之后，ORD002变成苹果6元、梨4元。这里用sku作为过滤条件比用name更可靠，因为同一商品可能有不同规格，name不一定唯一。

如果想给所有订单中价格大于5的商品打8折，可以配合arrayFilters和数值计算更新（需要MongoDB 4.2以上支持聚合管道更新）：

db.orders.updateMany( {status: "paid"}, [ {$set: { items: { $map: { input: "$items", as: "item", in: { $cond: [ {$gt: ["$$item.price", 5]}, {$mergeObjects: ["$$item", {price: {$multiply: ["$$item.price", 0.8]}}]}, "$$item" ] } } } }} ] )

这个更新用了聚合管道，批量遍历数组中的每个元素，条件判断后再改价格。这种写法比arrayFilters更灵活，但可读性差一些。我建议团队里保持统一：能用arrayFilters解决的简单更新用arrayFilters，涉及计算逻辑再用管道更新。

实操中还有一个容易忽略的点：更新后数据校验。改价会影响订单总金额，但上面管道更新只改了商品价格，没有同步修改payment.amount。实际业务里这种不一致会造成对账问题。所以数组更新操作要特别注意关联字段的同步。

7. 索引策略：让数组与嵌套查询跑得更快

7.1 为点路径创建索引

查询{"items.name": "苹果"}时，如果不建索引，MongoDB会做全集合扫描（Collection Scan）。数据量上来之后，这个查询会很慢。对点路径建索引的语法如下：

db.orders.createIndex({"items.name": 1})

MongoDB会把数组中的每个元素都作为索引条目。查询“数组中是否存在某个name”时，走的是多键索引（Multikey Index）。这个索引不仅能支持{"items.name": "苹果"}，也能支持{"items.name": {$in: [...], $all: [...]}}这类匹配。

重要的是，不能对数组子文档整体建索引，只能对数组里的具体字段建索引。{"items": 1}这种索引实际意义不大，因为数组本身作为整个字段的索引条目，查询时会被当成精确匹配来使用，而业务查询都是用元素字段。

7.2 复合索引与$elemMatch的配合

复合索引在数组场景下需要注意字段顺序。假设我们经常查询{"items.name": "苹果", "items.qty": {$gt: 1}}这种并列点路径条件，建一个{"items.name": 1, "items.qty": 1}的复合索引，查询优化器会尝试利用索引进行过滤。

但有一个让人意外的限制：复合索引中如果有多个字段来自同一个数组，索引无法同时满足同一数组元素的多字段匹配。具体来说，{"items.name": 1, "items.qty": 1}这种索引对于$elemMatch条件的支持并不好，因为多键索引的条目是笛卡尔积式的，对于数组里的每个name和每个qty都生成了组合索引项。查询优化器可能会退化为部分匹配甚至全扫描。

在这个问题上，官方建议是：当使用$elemMatch时，通常只在一个数组字段上创建索引，其他字段的过滤靠文档级其他的条件或应用层逻辑。如果一定要优化，可以考虑把数组拆出来单独建集合（类似于关系型的子表），但这又会打破文档模型的设计初衷。

我的经验是：先看真实查询模式，如果大部分查询是“按name过滤，qty只是次要过滤”，只建{"items.name": 1}就够；如果qty的过滤会显著减少结果集，再考虑把qty单独作为普通字段冗余到文档顶层。这种折中在实际项目中很常见。

7.3 数组索引对写性能的影响

多键索引的维护成本比普通索引高，因为插入或更新一条带数组的文档时，可能要为数组中的每一个元素更新索引条目。如果数组很长，例如每个订单有几十上百个商品，索引写放大问题会很明显。对热点数据集合，需要监控写延迟和索引大小。

另外，索引的键值总长度有限制。数组索引如果元素值特别大，会超过索引键限制（MongoDB的索引键最大通常为1024字节）。在存储长字符串数组时，超限会导致索引创建失败或写入失败。这时候要么缩短字段长度，要么换用哈希索引，或者考虑拆分数据。

索引设计上还有一个老生常谈但特别容易被忽略的事：$elemMatch中的字段和点路径查询的字段，是否能走索引，取决于查询优化器的选择。你可以在explain()里看执行计划，确认是否有效利用了索引：

db.orders.find({ items: { $elemMatch: { name: "苹果", qty: {$gt: 1} } } }).explain("executionStats")

观察winningPlan中是否出现IXSCAN，以及executionStats.totalDocsExamined是否远小于集合总数。如果totalDocsExamined接近全表行数，说明索引没有生效或者无法使用。

8. 常见问题与排查技巧实录

8.1 踩坑最多的《点路径字段交叉命中》

前文已经反复强调，但这里还是要专门整理一下。问题场景是这样：集合中某条订单的items包含两个子文档，一个是{name: "apple", qty: 1}，另一个是{name: "pear", qty: 2}。

执行：

db.orders.find({"items.name": "apple", "items.qty": 2})

这条查询会匹配该订单，因为name来自第一个元素，qty来自第二个元素。业务人员通常期望的是“同一个商品既叫apple数量又是2”，结果却被多个商品的数据组合骗过。排查这类问题最快的办法是把查询改成$elemMatch，语义立即精准。

我自己在实际运营后台遇到过类似情况：筛选“订单中同时包含商品A和商品B”时，误用了两个点路径条件并列。结果订单只要同时有A和B中的任意商品，甚至不同商品满足两个条件也会被查出来，导致优惠券发放范围严重扩大。

8.2$elemMatch位置不对导致查询无效

$elemMatch的语法位置容易写错。比如：

db.orders.find({ "items.name": {$elemMatch: {$eq: "apple"}} })

这种是错的，因为$elemMatch只能作用在数组字段上，不能作用在点路径后的字符串字段上。正确写法是：

db.orders.find({ items: {$elemMatch: {name: "apple"}} })

还有一种情况，对象数组里只想对某个字段做多条件匹配，比如price同时满足$gt和$lt，有人会写：

db.orders.find({ items: {$elemMatch: {price: {$gt: 4, $lt: 6}}} })

这个写法是对的，同一元素price既大于4又小于6。但如果你改成：

db.orders.find({ "items.price": {$gt: 4, $lt: 6} })

这是不对的，因为点路径会在所有元素中分别比较$gt和$lt，如果数组中有一个元素price=5，另一个price=12，第二个条件也能匹配（12 > 4 和 12 > 6？实际上12大于6导致整个$gt:4, $lt:6条件不能像多字段对象那样同时应用于同一个值）。等等，这里我需要更精确地解释：{"items.price": {$gt: 4, $lt: 6}}对于单个标量数组，当元素是价格数字时，条件作用于同一个元素，是可以正确筛选元素在4到6之间的。但对象数组里，如果点路径items.price等价于标量数组（所有price值组成的数组），$gt:4,$lt:6同时作用于同一个标量值。所以并不会出现“不同元素分别命中不同条件”的情况。不过对于对象数组的其他字段条件，比如{"items.price": {$gt: 4, $lt: 6}, "items.qty": {$gt: 2}}，此时price和qty才可能来自不同元素。这是我需要小心的表述，避免误导。

重新梳理：对于同一个字段（比如price），{"items.price": {$gt: 4, $lt: 6}}要求存在一个价格同时大于4且小于6，逻辑是正确的。但一旦加上另一个字段qty条件，两个字段独立匹配，就可能交叉命中。所以不能简单说“这是不对的”，应该说“如果只针对一个字段，没问题；如果针对多个字段，有交叉命中的风险”。

在博文里，我打算给出这个精确区分。

8.3 数组为空时的$all和$elemMatch行为

很多查询在数组为空时不返回任何结果。比如空数组items: []，用{"items.name": "苹果"}不会匹配。如果要筛出“没有添加任何商品”的订单，正确方法是：

db.orders.find({items: {$size: 0}})

或者用$exists+ 非空：

db.orders.find({items: {$exists: true, $ne: []}})

$size有局限性，它不能配合其他操作符比如$gt使用（老版本），虽然MongoDB 5.0开始支持$size与比较操作符组合。新版本中，计算数组长度的聚合表达式$size也可以用于查询，但普通查询中$size依然只能指定精确长度。有意思的是，$elemMatch不会匹配空数组，这是自然逻辑。

如果你的业务需要“不存在任何满足条件的元素”，用$not配合$elemMatch，但空数组时$not条件是成立的，因为“不存在任何元素”意味着也确实不存在满足条件的元素。这里要看业务语义，有时候空数组应该被排除，有时候应该包含，写查询时要先想清楚。

8.4 嵌套层级过深时的查询陷阱

点路径查询{"a.b.c": 1}在字段结构不一致时可能造成误匹配。比如有些文档里a不是对象，而是数组[{b: {c: 1}}, {b: {c: 2}}]，点路径同样会把a.b.c解析为数组的字段分支。如果业务上a既有对象形态又有数组形态，查询结果会出乎意料。

对这种数据结构混乱的情况，建议用聚合管道$type或$expr做类型判断。比如过滤a是对象而不是数组：

db.test.find({ a: {$type: "object"}, "a.b.c": 1 })

$type: "object"保证a是对象，排除数组分支干扰。

另外，点路径里的字段名如果本身包含点号，比如{"a.b": 1}，需要转义才能查询。MongoDB 5.0之后支持带点号字段名，但建议设计数据模型时避免这类字段名，否则每个查询都要写{"a\\.b": 1}，非常麻烦。

8.5 性能排查：从explain()看执行计划

数组查询的慢未必是语法问题，更多是索引和写法不匹配。排查步骤通常这样：

1. 用explain("executionStats")查看执行计划。
2. 检查stage是否为COLLSCAN，是的话基本可以判定没走索引。
3. 查看totalDocsExamined和totalKeysExamined，如果索引命中了大量文档，但过滤后剩很少，可能复合索引字段顺序有问题。
4. 对$elemMatch查询，确认索引是否基于同一个字段，必要时把条件改为“前缀字段”+“非数组字段”的复合索引。

再给一个我常用的检查索引命中情况的方法：创建一个只包含必要字段的小数据集，用explain对比不同写法的索引使用。虽然数据量小时看不出性能差异，但能从执行计划里看到索引是否被采用。

8.6 数组更新中的并发问题

当多个请求同时$push同一个数组时，MongoDB的原子性保证整个文档的更新是原子的，不会出现数据错乱，因为更新是文档级别的。但如果业务需要对“是否存在再更新”做判断，比如“不存在sku就push，存在则更新数量”，直接先查后改会有竞态条件。更好的做法是用$addToSet加一个唯一标识字段，但$addToSet不能做“存在则更新”的合并操作。

MongoDB 4.2之前只能依赖文档锁（实际上更早的版本是库锁或MMAP锁），之后通过事务可以保证多个操作的原子性。简单场景下，也可以用聚合管道更新的方式，在管道里判断，而不是分两步。比如：

db.orders.updateOne( {orderNo: "ORD001"}, [ {$set: {items: { $cond: { if: {$in: ["sku_apple", "$items.sku"]}, then: { $map: { input: "$items", as: "item", in: { $cond: [ {$eq: ["$$item.sku", "sku_apple"]}, {$mergeObjects: ["$$item", {qty: {$add: ["$$item.qty", 1]}}]}, "$$item" ] } } }, else: {$concatArrays: ["$items", [{sku: "sku_apple", name: "苹果", price: 5, qty: 1}]]} } }}} ] )

这段更新用聚合管道完成“存在则数量+1，不存在则插入”的完整逻辑。虽然看起来复杂，但避免了应用层先查后改的并发陷阱。这种写法在订单合并、购物车操作里非常实用。

9. 一些我沉淀下来的实操建议

上面讲了很多语法和案例，最后聊几句我在实际项目里反复验证过的体会。

数组和嵌套文档最怕的是“模型不固定”。MongoDB的schema-free特性很容易让人松懈，但一旦数组元素结构不一致，查询逻辑就会变得极其复杂。不管是数组里的子文档还是嵌套对象，都建议在应用层做校验，至少保证核心字段的类型和存在性一致。

$elemMatch是数组对象查询中最刚需的操作符，但它不是万能的。当过滤条件既有数组字段又有文档顶层字段时，建议把顶层字段单独拎出来做复合索引。比如经常查“订单状态为paid且items里包含苹果”，建{status: 1, "items.name": 1}比只建{"items.name": 1}效果好得多，因为查询优化器可以先用status过滤。

另外，宁可在文档顶层冗余一个总数量字段，也不要每次从巨型数组里计算。比如订单文档保留totalQty字段，每次$push、$pull时同步更新，看起来浪费存储，但查询时性能提升巨大。用聚合管道做实时统计虽然方便，但面对千万级订单量时，每一次扫描数组都是不小的开销。

数组更新中的arrayFilters是提升代码可读性的利器，强烈建议统一使用。很多老代码里用$占位符嵌套更新，条件稍微复杂一点就写不对，arrayFilters能让你显式控制哪个元素被更新，代码也更容易review。

最后是关于聚合管道更新。如果团队里有人不熟悉聚合操作，宁可多写几条查询加更新，也不要一开始就上复杂的$map、$reduce。管道更新一旦写错，影响的是整批数据，且不容易追溯。先从简单直接的更新开始，优化性能时再考虑管道方案。

写到这里，数组与嵌套文档的查询和更新体系基本都覆盖了。MongoDB这套语法不难，但细节陷阱很多，希望这些案例能帮你少踩几次坑。