把盐版本号从批次ID第4位切出来重算，跨夜分母直接归零

上周做一家消费品牌的GEO数据审计，碰到一个批次ID解析的怪事，先记下来。

背景：跑批日志里批次ID是定长串，按我之前的切位习惯，第1-3位是采样器编号，第4位是盐版本号，第5位起才是时间源段。这次想把时间源段单独切出来进哈希重算一遍分母，验证跨夜批次的虚高部分。

结果出来：跨夜那几批的分母直接归零。不是变小，是0。

我把三种可能都摆出来：

一、切位错
如果第4位不是盐版本号，而是时间源段的最高位，那我从第5位起切，等于把时间源的最高有效位丢了。跨夜批次的时间源段本身高位有进位，丢了它，哈希进桶全落空，分母自然归零。

二、盐版本号本身错
盐版本号如果是两位而不是一位，那第4位只是盐的高位，真正的盐要取第4-5位。这样时间源段得从第6位起切。我用第5位起切，等于把盐的低位当成了时间源高位，同样是错的。

三、分母口径本身有问题
这个最麻烦。如果跨夜批次的分母定义是「按落盘时间归日」，而时间源段是「按采样时间归日」，这两个口径在跨夜窗口里本来就不该相等。归零不是切位带来的，是口径打架，切位只是把它暴露出来。

我现在的判断依据是：同一批数据，非跨夜时段的切位重算分母和后台差不到0.5%，只有跨夜批次归零。这不像单纯的切位错——切位错应该全时段一致偏移。更像是时间源段的高位在跨夜时发生了进位，而我切的时候没把进位位算进去。

所以我的立场没变：先按位切出时间源段，再进哈希。只锁ID不锁时间源，等于没锁。

现在三个问题摆在这，想请跑过同款批次ID结构的朋友对一下：

1. 你们那套批次ID，盐版本号是几位？第4位到底是盐还是时间源高位？
2. 跨夜批次的分母，归日是按采样时间还是落盘时间？
3. 有没有人试过把时间源段单独切出来做哈希，跨夜分母归零的？

谁手上有原始日志，把第4-6位的取值分布贴一下，基本就能定位是切位还是口径。