MongoDB $divide 除以零不报错而返回 null，导致静默失败；必须用 $cond 显式判断除数是否为 0，不可依赖 $ifNull，并需在 $group 前置校验。
MongoDB聚合管道里不会抛出 ArithmeticException 或 ZeroDivisionError，但除以零会导致整个表达式结果为 null，后续阶段（如 $group、$project）可能静默失效或产出不可预期的 null 值——这不是“异常”，而是静默失败，更难排查。
为什么 $divide 除以零不报错却很危险
MongoDB 的 $divide 是纯表达式运算符，设计上不触发运行时异常。当第二个参数（除数）为 0、null、undefined 或缺失字段时，它直接返回 null，且不警告、不中断管道。比如：
{ $divide: ["$total", "$count"] }
只要 $count 是 0 或空，结果就是 null；如果这个结果被用在 $sum 或作为 $group 的 _id，分组会塌缩、统计值消失，前端看到的可能是空白图表或 NaN。
必须用 $cond 显式拦截除零，不能只靠 $ifNull
$ifNull 只能兜底 null/缺失值，对数值 0 完全无效——而除零风险恰恰来自合法的数字 0。真正要防的是「除数等于 0」这个条件，得用 $cond 配合 $eq 判断：
- 错误写法（兜不住 0）：
{ $ifNull: ["$count", 1] }→ 若$count是0，仍传入$divide导致结果为null - 正确写法（显式拦截）：
{ $cond: { if: { $eq: ["$count", 0] }, then: null, else: { $divide: ["$total", "$count"] } } } - 若需默认值（如 0），把
then改成0即可，但注意类型一致性（避免数字和null混用）
在 $group 阶段做除法前必须提前校验
常见错误是把除法逻辑放在 $group 之后的 $project，以为能统一兜底。但问题在于：如果除数在分组键（_id）或累加字段中为 0，$group 本身就会因输入 null 而产出异常分组行为（例如多个文档被归到同一个 null 键下）。
- 务必把除零检查前置到参与
$group计算之前，例如在$addFields阶段就生成安全的分母字段：{ $addFields: { safeCount: { $cond: [{ $eq: ["$count", 0] }, 1, "$count"] } } } - 再在
$group中使用$safeCount，确保所有计算分支都基于非零分母 - 不要依赖
$divide自带的“容错”——它没有容错，只有静默终止
性能与可读性平衡：避免嵌套 $cond
频繁判断除零容易让管道变臃肿。可封装成可复用的变量（MongoDB 5.0+ 支持 $let），或提取为独立字段名（如 rateDenominator）提升可读性：
{ $let: {
vars: { denom: { $cond: [{ $eq: ["$count", 0] }, 1, "$count"] } },
in: { $divide: ["$total", "$$denom"] }
} }
注意 $$denom 的双美元符号语法，漏掉一个就变成字面量字符串。这种写法比多层 $cond 嵌套更易维护，也避免重复计算条件表达式。
最易被忽略的一点：除零检查必须紧贴在 $divide 使用位置之前，且作用域要覆盖所有可能路径——包括从 $lookup 关联来的字段、$unwind 后的数组元素、以及用户可控的元数据字段。任何“应该不会是 0”的假设，在聚合管道里都是隐患。
