$match无法直接比较同一文档的两个字段，因为它只进行字面值匹配，将"$sample"视为字符串而非字段引用；字段间比较需用$expr配合$eq等表达式操作符。
为什么 $match 无法直接比较同一文档的两个字段
因为 $match 只做「值过滤」，不支持字段间动态比较。比如你想写 { bucket: { $eq: "$sample" } }，MongoDB 会把它当成字面量字符串 "$sample" 去查，而不是取当前文档的 sample 字段值。
真正能做字段间比较的是 $expr，它启用表达式上下文，允许用 $ 引用字段。
- 错误写法：
{ bucket: "$sample" }—— 这是匹配字段值等于字符串"$sample" - 正确写法：
{ $expr: { $eq: [ "$bucket", "$sample" ] } } - 注意：数组形式传参，顺序无关，但必须是字段引用（带
$）或字面量
$bucket 阶段要求分组键必须是数值，且不能直接用 $sample 当键
$bucket 的 groupBy 表达式必须返回一个数字；如果 sample 是字符串、布尔或缺失字段，整个文档会被丢进 default 组（或报错，取决于配置）。
常见翻车点是没做类型兜底 —— 比如 sample 字段混着存了 "123"（字符串）和 123（数字），$bucket 会静默失败或归入 default。
- 安全做法：用
$convert或$toDouble强转，例如{ $toDouble: "$sample" } - 加
$cond处理空值：{ $cond: { if: { $ne: [ "$sample", null ] }, then: { $toDouble: "$sample" }, else: -1 } } - 别忘了设
default：否则类型转换失败的文档直接消失
想看 bucket 和 sample 分布是否一致？先用 $addFields 对齐再统计
直接比字段值没意义，得看它们落在相同桶里的比例。典型做法是：对 sample 做一次 $bucket 得到 sampleBucket，再用 $match 看 sampleBucket 是否等于原始 bucket 字段。
这本质是验证数据标注质量或 ETL 逻辑是否稳定。
- 先算出
sample应属的桶：{ $addFields: { sampleBucket: { $bucket: { groupBy: { $toDouble: "$sample" }, boundaries: [0, 10, 20, 30], default: "other" } } } } - 再筛选匹配项：
{ $match: { $expr: { $eq: [ "$bucket", "$sampleBucket" ] } } } - 最后
$count或$group算覆盖率，比如{ $group: { _id: null, matched: { $sum: 1 }, total: { $sum: { $cond: [{ $ne: ["$bucket", null]}, 1, 0]} } } }
聚合里字段名冲突和阶段顺序容易导致“查得到但不对”
如果你在 $bucket 后又用了 $addFields 覆盖了 bucket 字段（比如重命名或计算新值），后续 $match 用的就不是原始 bucket，而是覆盖后的值 —— 但错误日志里根本不会提醒你字段被覆盖了。
更隐蔽的是：$bucket 输出的 _id 默认就是桶范围，但如果你手动 $project 出一个叫 bucket 的字段，它和原始 bucket 字段就不是一回事了。
- 调试技巧：在关键阶段后加
$limit: 1+$project查看字段实际值，比如{ $project: { bucket: 1, sample: 1, sampleBucket: 1, _id: 0 } } - 避免覆盖：给计算字段起明确名字，比如
expectedBucket、computedBucket，别贪图省事叫bucket - 边界值敏感：如果
boundaries是[0,10,20]，那10落在第二桶（[10,20)），但sample是浮点数时可能因精度偏差跨桶
