该页面围绕“等宽分桶，否则不分桶”的原则，讨论如何为范围图设计分桶，并给出 Kotlin 代码示例与验证命令。
用途：页面针对范围图（range chart）中的分桶设计，说明桶宽与桶数量是两个彼此独立的决策，二者都会影响图表的可读性与准确性。
主要能力与观点：
- 按读者实际会阅读的行数选择桶单位：7天对应7个日行，30天对应4个周行，90天对应3个月行。先确定阅读单位，再让算术服从这一决定。
- 采用完全等宽的桶，把余数放在图表之外。示例中四个7天的桶覆盖名义30天中的28天；理由是另一种做法（四个半桶覆盖30天）会让一个桶有9天、另外三个只有7天。
- 不等宽桶会引入方向已知的偏差：桶越宽，收集的事件计数越多，条形越长，读者会误以为活动更多，看起来像趋势，这比噪声更糟。
- 丢弃余数只有在标签可发现时才诚实：每个桶标注各自的起止日期，读者能看出图表从28天前开始；若只标“Week 4”而不带日期，被丢弃的天数就不可发现，图表下方总计也会与屏幕其它位置的总计不一致。
- 日历月本身不等宽，仅在标签明确单位时才允许，例如标签写明月份；标签为“bucket 3”的九宽桶不可接受。该豁免覆盖月和季度，不覆盖其它自创单位。
- 最新的日历桶往往是进行中的部分区间，却按全宽绘制，会造成每月都出现的“看似骤降”。页面列出三种修复方式：排除进行中的单位、按已过时间比例缩放该桶、或标注“so far”；但不能放任不管。
- 桶顺序是桶约定的一部分，渲染器不会修正：示例四个分支中三个按最新在前，年份分支按一月在前，渲染器只是对列表做 forEach，类型系统不会发现方向不一致。应在构建列表处确定方向并断言。
- 包含式结束边界需要排他式查询上界：描述为 [start, end] 的桶应查询为 start .. end.plus(1 day)（或到 23:59:59），否则每个桶最后几小时的事件会落入下一个桶，形成图表上不可见、只有总计无法对账时才暴露的静默重分配。
- 零值桶仍须占一行，计数须放在条形之外：使用下限钳制（coerceIn(0.001f, 1f)）让空桶以细线可见，这是对的，因为空桶通常正是信息；但若计数标签画在条形内部，在该填充度下会落在轨道上并使用条形前景色。同功能中的另一图表把计数放在轨道右侧固定宽度列中，这种布局在零值下仍然成立。
- 按本地小时或本地日分桶应在代码中完成而非 SQL；被分桶的时间戳含义可能与列类型暗示的不同。无法覆盖全部输入的分桶集属于“部分图表必须说明”的时间情形。
使用方式：页面给出一段 Kotlin 示例，展示最近30天分支如何构造四个恰好7天的桶（最新在前，余数留在图外）。验证部分提供三条只读命令，需在仓库根目录运行：用 grep 找出所有分桶构建分支以检查宽度算术与方向；用 awk 重新推导桶集覆盖范围（示例 n=4、len=7 输出“covered 28 of the 30 nominal days”）；用 grep 检查包含式结束转换和所有条形图的填充下限（两个下限相差20倍往往说明其中一个是为画在条形内的标签调过的）。
适用场景：适用于需要按时间范围绘制条形范围图、并希望避免分桶偏差与读者误读的 Android/Kotlin 图表代码；也适合作为代码审查与验证清单。
限制：页面内容为设计经验与代码示例，未提供安装方式、依赖、版本要求或性能数据；示例中的具体天数、桶数与验证命令参数需按实际代码调整。