$bucket 和 $bucketAuto 不能直接对布尔值分桶，因其要求 groupBy 输出可排序的数值或日期类型；布尔值不支持边界比较，会报错或行为异常。
不能直接用 $bucket 或 $bucketAuto 对布尔值（true/false）做分桶 —— 它们要求 groupBy 表达式输出**可排序、有自然顺序的数值或日期类型**，而布尔值在 MongoDB 中不支持边界比较，强行传入会报错或行为不可控。
为什么 $bucket 传 $isOnline 会失败
MongoDB 的 $bucket 阶段在解析 boundaries 数组时，会对每个文档的 groupBy 结果与边界值做严格类型匹配和大小比较。布尔值既不能和数字比较（true > 0 返回 false），也不被允许出现在 boundaries 中（驱动或服务器会直接拒绝数组含 true/false）。常见错误现象包括：
errmsg: "boundaries array must contain at least two elements of the same type"errmsg: "cannot compare boolean to number"- 聚合静默跳过文档，或全部归入
default桶（当指定了default且类型不匹配时）
把布尔转成数值再用 $bucket
最稳妥的做法是先用 $cond 把布尔字段映射为整数（如 1 和 0），再喂给 $bucket。注意边界必须覆盖这两个离散值，且顺序严格升序：
{ $bucket: {
groupBy: { $cond: { if: "$isActive", then: 1, else: 0 } },
boundaries: [0, 1, 2],
default: "invalid",
output: { count: { $sum: 1 } }
} }
这个写法会生成两个桶：_id: { min: 0, max: 1 }（对应 false）、_id: { min: 1, max: 2 }（对应 true）。关键点：
-
boundaries必须至少含 2 个值，且按升序排列；[0, 1, 2]是安全选择，避免因浮点精度或隐式转换出错 - 不要用
[0, 1]—— 这只产生 1 个桶（[0, 1)），true → 1会溢出到default - 如果原始布尔字段可能为
null，$cond的else分支要显式处理，否则null会被当成false
用 $bucketAuto 处理布尔值？不推荐
$bucketAuto 要求所有 groupBy 值都是数值且非 NaN，才能启用 granularity 优化。但即使你用 $cond 转成了 0/1，$bucketAuto 仍会试图“均匀分布”——对只有两个取值的数据，它大概率只生成 1 个桶（把 0 和 1 都塞进去），完全失去分类意义。实测中：
-
buckets: 2通常仍返回 1 个桶（因算法认为 0 和 1 太接近，无法切分） -
buckets: 3可能生成 2 个桶，但边界可能是[0, 0.5)和[0.5, 1]，导致1全部进第二个桶，0全进第一个，看似可行但依赖内部启发式，不保证跨版本一致 - 一旦数据里混入
null或其他类型，$bucketAuto直接报错："all groupBy values must be numeric"
更简单直接的替代方案：用 $group + $cond
对纯布尔分类，$group 更清晰、无歧义、性能更好：
{ $group: {
_id: "$isActive",
count: { $sum: 1 },
avgScore: { $avg: "$score" }
} }
它天然支持布尔值作 _id，输出就是两行：{ "_id": true, "count": 123 } 和 { "_id": false, "count": 456 }。相比 $bucket，省去边界维护、类型转换、default 分支等额外心智负担。唯一要注意的是：$group 不会输出 0 计数的分组（比如没有 false 文档时不会补一条 {_id: false, count: 0}），如有此需求，得靠应用层补全或用 $facet 配合空集合模拟。
真正需要 $bucket 的场景，是当你面对连续数值（比如响应时间、价格、温度）并想按区间统计时；拿它硬套布尔值，就像用扳手拧螺丝——能转，但费劲还容易滑丝。
