$bucketAuto 是识别离群值的合理起点，因其是 MongoDB 中唯一能在服务端稳定近似计算 Q1/Q3 的聚合阶段，避免全量数据传输与客户端性能瓶颈。
为什么 $bucketAuto 是识别离群值的合理起点
因为 MongoDB 没有原生的 PERCENTILE_CONT 或 quantile() 聚合函数，$bucketAuto 是目前唯一能在服务端稳定、近似计算四分位数（Q1/Q3）的聚合阶段。它不依赖客户端拉取全量数据，避免了 pandas 或 Node.js 中遍历集合的性能瓶颈，特别适合文档量 > 10 万的集合。
用 $bucketAuto 计算 Q1 和 Q3 的实操要点
关键不是“分 4 个桶”，而是让每个桶覆盖等频次的数据区间——$bucketAuto 的 buckets: 4 确保每桶约含 25% 文档，此时第 1 桶上界 ≈ Q1，第 3 桶上界 ≈ Q3。
- 必须对目标字段（如
"res"）使用"groupBy": "$res"，不能写成"groupBy": {"$toDouble": "$res"}，否则会跳过非数字值且不报错 - 如果字段存在
null、缺失或字符串值，$bucketAuto会静默忽略它们，导致 Q1/Q3 偏移；建议前置$match过滤：{"res": {"$type": "number"}} - 桶数量严格设为
4；设成5或10会导致$arrayElemAt取索引失败，Q1 不再是索引0，Q3 不再是索引2
组合 pipeline 时最容易漏掉的两步
只靠 $bucketAuto 得不到离群值 ID，后续必须补全逻辑链：先提取阈值，再反查原始文档。漏掉任一环节都会返回空结果。
-
$group后必须接$sort：因为$bucketAuto输出的max字段不保证升序，直接$push会导致maxs[0]实际是 Q3 -
$lookup的pipeline内必须用$expr包裹条件，不能写{"res": {"$lt": "$outlierThresholdLower"}}——这种写法会把变量当字面量，永远查不到数据 -
$lookup返回的是数组字段outliers，最终要提取 ID 需追加$project：{"_id": {"$map": {"input": "$outliers", "as": "o", "in": "$$o._id"}}
性能与精度的现实权衡
$bucketAuto 给出的是近似四分位数，尤其在数据分布极不均匀（如长尾、大量重复值）时，Q1/Q3 可能偏移 5–10%。但它换来了免传输、免内存的压力释放。
- 若集合有亿级文档，用此法耗时通常在 2–8 秒；用客户端计算需拉取全部
res值，网络+内存开销常超 30 秒甚至 OOM - 不要试图用
$bucketAuto+buckets: 100提高精度——桶越多，各桶文档数越不均，反而削弱分位估计稳定性 - 真正影响业务判断的，往往不是 Q1 精确到小数点后三位，而是能否快速圈出 top 0.5% 的可疑值；这时近似解就是实用解
实际跑通的关键，是接受「服务端分位≈足够好」这个前提，并守住 $bucketAuto → $sort → $group → $lookup 这条不可简化的链路。任何想绕过 $lookup 直接在分桶阶段标记离群文档的做法，都会因无法关联原始 _id 而失败。
