正确去重需两层$group：首层用复合_id（如{user_id:"$user_id",com_id:"$com_id"}）分组并$first取代表文档；次层按user_id分组，用$sum统计comNums等汇总字段，且$sort必须在$group前、$skip/$limit在次层$group后。
用 $group 对多条子文档做去重分组，关键在 _id 设计
一对多关系（比如一个 user_id 对应多个 com_id）要做去重，本质不是删数据，而是“按主键组合分组 + 每组只取一条代表”。$group 的 _id 必须包含能唯一标识“逻辑主记录”的字段，例如 { user_id: "$user_id", com_id: "$com_id" }。如果只写 "$user_id"，那后续再 $group 一次才能聚合到用户级，但中间会丢失原始明细的关联性。
常见错误是直接对 user_id 分组后用 $first 取任意一条 com_id，结果看似去重了，实则把不同 com_id 合并成了一条，造成业务数据丢失。
- 正确做法：第一层
$group用复合_id（如{ user_id: "$user_id", com_id: "$com_id" }），确保每组只含同一 user+com 组合的文档 - 再用
$first或$max提取该组内最新/最全的字段（如"name": { "$first": "$name" }） - 若需最终按 user 汇总（如统计该用户关联多少个 com），必须加第二层
$group，以"$user_id"为_id，再用$sum: 1算comNums
$first 和 $last 依赖前置 $sort，不排序就是随机取
很多人以为 $first 是取“最早插入”的那条，其实它只取管道中当前顺序的第一条——而这个顺序由上一阶段决定。如果没显式 $sort，MongoDB 不保证文档返回顺序，$first 结果不可控。
例如想保留每个 unique_path 下 modified 最新的那条记录，必须先 { "$sort": { "unique_path": 1, "modified": -1 } }，再 $group 时用 "$first": "$$ROOT" 才可靠。
- 排序字段要包含分组键（如
unique_path）和时间/优先级字段（如modified），否则跨组排序无意义 - 如果业务要求“取创建时间最早的”，就用
"modified": 1升序，再配$first - Spring Data MongoDB 中，
Aggregation.sort()必须放在Aggregation.group()前面，否则无效
分页必须放在最后两层 $group 之后，否则跳过的是分组前的原始文档
聚合里 $skip / $limit 的位置极其关键。如果把它们插在第一次 $group 后、第二次 $group 前，相当于对“user+com”粒度的结果分页，而不是对最终“user”粒度的结果分页——页面数和总数对不上，前端翻页会漏数据或重复。
典型结构是：match → sort → group（user+com）→ group（user）→ skip/limit → sort（最终排序）。其中最终 sort 也得放在 skip/limit 后面，否则排序被截断。
- Spring Boot 中，
Aggregation.skip()和Aggregation.limit()要紧贴在第二次$group之后、最终Aggregation.sort()之前 - 分页参数计算：若每页 10 条，第 3 页应为
skip(20)，不是skip(30)；注意(pageNum - 1) * pageSize别算错 - 别在
$match阶段用$in传超大数组（如几万 user_id），可能触发 BSON 大小限制或慢查询，考虑拆批或建索引
去重后汇总字段（如 serverNums）要用 $sum，别误用 $first
汇总类字段（总数、金额、数量等）必须用 $sum 累加，不能用 $first 或 $max 替代。前者是聚合语义，后者只是取值语义。
比如一个 user 有 3 条记录，server_nums 分别是 5、8、3，期望汇总值是 16。如果第二层 $group 写成 "serverNums": { "$first": "$serverNums" }，结果永远是 5；而 "serverNums": { "$sum": "$serverNums" } 才正确。
-
$sum支持字段路径（"$server_nums"）和常量（1），后者常用于计数（如"comNums": { "$sum": 1 }） - 如果字段可能为 null，
$sum会跳过，无需额外$cond判断；但$first遇到 null 也会照取，可能污染结果 - 涉及浮点数累加要注意精度，MongoDB 默认 double，业务敏感场景建议在应用层校验或转整型存储
实际执行时最容易被忽略的是：两次 $group 之间的字段投影是否完整。第一层分组后，若没用 $first 把 name、dept_names 等字段带出来，第二层就无法访问——这些字段不会自动继承，必须显式声明。
