$elemmatch是嵌套数组查询的唯一可靠方式，因其强制在同一数组元素内匹配多个条件，避免跨元素误匹配；点号查询{"meta.tags":"urgent","meta.status":"active"}会导致笛卡尔积式错误。
用 $elemMatch 精确匹配嵌套数组中的对象
直接用点号路径（如 comments.author）做查询，会跨数组元素匹配——比如想找“作者是 Alice 且内容含 bug 的评论”，但实际可能匹配到两个不同评论分别满足条件。必须用 $elemMatch 才能保证所有条件落在同一个数组元素上。
常见错误现象：查出空结果，或查出不该出现的文档，本质是没意识到 MongoDB 默认对数组做“宽松匹配”。
-
comments: { $elemMatch: { author: "Alice", content: { $regex: "bug" } } }—— 正确：同一条评论同时满足两个条件 -
comments.author: "Alice", comments.content: { $regex: "bug" }—— 错误：可能从两条不同评论中各取一个字段 - 如果只查单个字段（如
comments.author: "Alice"），不用$elemMatch也行，但语义清晰起见仍建议加上
用 $ 投影操作符提取匹配到的数组元素
查到文档后，默认返回整个 comments 数组；若只想返回匹配的那条评论（不是全部），得在 projection 中用 $ 操作符。它只作用于被 $elemMatch 或等价查询条件命中的第一个匹配项。
使用场景：API 返回精简数据、避免传输冗余嵌套内容。
-
{ comments: { $elemMatch: { author: "Alice" } } }是 query 部分 -
{ comments: 1 }返回整个数组；{ "comments.$": 1 }只返回第一个匹配的评论对象 - 注意：
$不支持多层嵌套投影（比如comments.replies.$），只能用于最外层数组
深层嵌套数组（如数组里还有数组）怎么办
MongoDB 原生不支持直接定位二级嵌套数组里的元素（例如 comments.replies.author）。必须用聚合管道，靠 $filter + $map 逐层收缩。
性能影响明显：无法走索引，全量展开数组再过滤，大数据量时延迟高。
- 先用
$filter在comments层筛选出含目标replies的评论：{ $filter: { input: "$comments", cond: { $gt: [{ $size: { $filter: { input: "$$this.replies", cond: { $eq: ["$$this.author", "Bob"] } } } }, 0] } } } - 再对每条匹配评论的
replies做二次$filter，取出具体对象 - 如果高频查询这种结构，应考虑反范式化：把关键查询字段（如最高优先级 reply 的 author）提到外层字段，加索引
索引对嵌套数组查询是否有效
有效，但有严格前提：索引字段路径必须和查询路径完全一致，且不能跳过中间层级。
容易踩的坑是建了 comments.author 索引，却用 comments.content 查询——这个索引完全用不上。
- 单字段查询：给
comments.author建索引即可 - 多字段联合查询（用
$elemMatch）：必须建复合索引，顺序要和查询条件顺序一致，如{ "comments.author": 1, "comments.content": 1 } - 数组字段索引会为每个元素单独建条目，索引体积可能远大于原始数据，注意监控
indexSize
explain("executionStats") 看实际扫描文档数和内存使用。
