MongoDB中HAVING等效逻辑必须用$group后的$match实现，且聚合字段需显式命名才能被$match引用，错误放置会导致过滤原始文档而非分组结果。
在 $group 阶段后用 $match 过滤分组结果
MongoDB 没有 HAVING 关键字，但等效逻辑必须放在 $group 之后、且只能用 $match 实现——放错位置（比如写在 $group 前）就变成 WHERE，不是 HAVING。
常见错误是把条件写进 $group 的 $cond 或直接丢到 pipeline 开头，结果过滤的是原始文档，而非分组后的聚合值。
-
$match必须紧接在$group后，才能访问分组产生的字段（如$sum、$count等计算结果） - 不能在
$group内部“提前筛选”，MongoDB 不支持HAVING那种语法糖 - 如果需要多层条件（比如先筛 count > 5，再筛 avg > 100），多个
$match可连续写，MongoDB 会自动优化执行顺序
注意字段名作用域：分组字段必须显式投影
$group 输出的文档里，所有聚合值都必须有明确字段名；$match 能引用的，仅限这些命名后的字段。没命名的表达式（比如 {$sum: "$price"} 没赋给字段）在后续阶段完全不可见。
示例：想筛选订单数超 3 的用户，以下写法会失败：
{$group: {_id: "$user_id", {$sum: 1}}}
正确写法必须命名计数字段：
{$group: {_id: "$user_id", order_count: {$sum: 1}}}
之后才能写：
{$match: {order_count: {$gt: 3}}}
- 别依赖
_id做数值比较——它只是分组键，不是聚合结果 - 如果要用
$avg、$max等，同样必须赋值给字段名，否则$match查不到 - 字段名区分大小写，且不能含空格或点号（
.），否则查询时会报FieldPath field names may not contain '.'
性能关键：$match 尽量前置，HAVING 类逻辑无法下推
SQL 中 HAVING 条件无法下推到存储层，MongoDB 同理：$match 放在 $group 后，意味着所有分组都得先算完，再过滤。数据量大时极易 OOM 或超时。
- 能用
$match放在$group前过滤原始文档的，一定优先放前面（那是 WHERE） - 真正需要 HAVING 语义的场景（比如“平均订单金额 > 500 的城市”），无法避免全量分组，此时考虑加索引加速
$group的_id字段（如对city建索引） - 如果聚合结果集很大，可在
$match后立刻接$limit，减少后续阶段压力
嵌套分组时，HAVING 逻辑要逐层匹配
多级 $group（比如先按日期分组，再按地区分组）中，每层 $match 只能过滤当前层输出字段。不存在跨层引用，也不能跳过某层直接筛最外层结果。
例如两层分组：
[
{$group: {_id: "$date", city_stats: {$push: {city: "$city", sales: "$sales"}}}},
{$group: {_id: null, all_cities: {$push: "$city_stats"}}}
]
这时想筛“单日总销售额 > 10000”，必须在第一层 $group 后就用 $match，基于 $sum: "$sales" 字段判断；第二层输出的 all_cities 是数组，无法直接比较总和。
- 每层
$group后若需过滤，就得配一个对应的$match - 避免把聚合逻辑全堆在最后一层再筛——可读性差，也难调试
- 用
$addFields或$set预计算中间值，能让$match条件更清晰，但不改变执行开销
$match 看不见未命名的聚合表达式，也不会报错，只会静默跳过条件。调试时建议先跑通 $group，console.log 或用 Compass 查看中间输出结构，确认字段名和类型完全匹配，再加 $match。 
