聚合管道不是SQL替代品，必须按数据流向分阶段设计：$match须前置以提升性能，$unwind需加preserveNullAndEmptyArrays并立即过滤null，$group的_id结构决定分组准确性且需配合$sum/$cond精准计数。
直接上结论：聚合管道不是“写完就能跑”的 SQL 替代品，它必须按数据流向分阶段设计，且 $match 要尽可能前置、$unwind 要谨慎触发、$group 的 _id 结构决定后续能否正确分组——这三个点踩错一个，报表就出错或慢得没法用。
为什么 $match 必须放在聚合管道最前面？
这是性能和语义双重约束，不是建议而是硬规则。MongoDB 不会自动优化阶段顺序，$match 放后面等于让所有中间结果（比如展开后的几千条记录）都流过后续阶段，白白消耗内存和 CPU。
- 错误示例：
$unwind→$project→$match：假设原始文档含 100 条嵌套考勤记录，$unwind后变成 100 个文档，再$match过滤——这 100 个文档全已生成，哪怕最终只保留 5 条 - 正确做法：先
$match筛出目标日期范围 + 指定班级的文档，再$unwind，数据量可能从 1000 文档 → 200 文档 → 展开后仅 800 条，而非 1000×平均数组长度 - 特别注意：对数组字段做范围匹配（如
atndnc.date）时，$match必须写在$unwind之后——但这种情况极少，99% 的时间你该过滤的是外层字段（semester、section、subject）
怎么安全地处理 atndnc 这类嵌套数组字段？
嵌套数组是出勤率、订单明细、日志事件等报表的常见结构，$unwind 是必经之路，但极易引发数据膨胀或空数组崩溃。
-
$unwind默认遇到空数组或缺失字段会报错，加preserveNullAndEmptyArrays: true参数才能让这类文档保留并生成 null 值，避免整个管道中断 - 展开后必须立刻
$match过滤掉 null 记录（如{ "atndnc.attend": { $exists: true } }），否则$group会把 null 当作有效值参与计数 - 不要在
$unwind后直接$group：先$project提取关键字段（如rollno、attend、date），去掉无关嵌套层级，减少后续阶段处理负担 - 如果数组很大（>100 项），考虑是否真需要全部展开——有时用
$reduce或$filter在数组内完成条件统计更高效
如何让 $group 输出的字段名更干净、计算更准确？
$group 的 _id 是分组键，但输出字段名由你完全控制；$sum 和 $cond 组合才是条件计数的核心，别依赖应用层二次计算。
-
_id字段必须明确包含所有分组维度，例如按学生统计出勤率，_id: { rollno: "$rollno", name: "$name" }，漏掉name可能导致同名不同人合并 - 条件计数别写
$sum: { $cond: [ "$atndnc.attend", 1, 0 ] }—— 这里"$atndnc.attend"是路径，但$unwind后应为"$atndnc.attend"（已扁平化），路径错会导致全为 0 - 百分比计算必须在
$project阶段做，用$multiply和$divide，注意除零保护：{ $cond: { if: { $eq: ["$total", 0] }, then: 0, else: { $multiply: [{ $divide: ["$present", "$total"] }, 100] } } } - 输出字段别留
_id：除非你要用它做后续关联，否则$project中显式设_id: 0，避免前端解析出意外字段
真正卡住报表交付的，往往不是语法写不对，而是没想清楚数据从哪来、经过每阶段后结构怎么变、null 和空数组怎么兜底——这些细节不验证到具体文档样例上，光看文档永远调不通。
