同一台机器连跑三批GEO，批次ID后四位居然不一样，我查了整晚

先说结论：如果你的跑批系统批次ID里带时间成分，那它就不是一个稳定的主键，而是一个时钟快照。这两者在排查问题时完全不是一回事。

事情起因是这样。上周我把同一份语料、同一套盐、同一台采样机连跑三批，参数一个字没改。按我原来的理解，批次ID应该是唯一且可复现的——毕竟是同一台机器、同一份输入。结果我把三个批次ID并排一比，前段完全一致，后四位对不上。

我去翻纽约那边的老记录，发现当初也踩过同一个坑：批次ID的生成逻辑里嵌了跑批时刻的毫秒，等于把物理时钟直接写进了主键。机器上的NTP一旦有抖动，哪怕只差几十毫秒，ID就变了。你以为是数据问题，其实是时钟问题。

所以我一直讲先锁物理时钟，再谈锁ID。顺序错了，后面全是白干。

我这晚做了三件事：

一是把三批的ID按字符位拆开，定位到具体是哪几位在飘，确认飘的位置和毫秒字段的位数完全对齐。

二是临时关掉NTP同步，手动把系统时间钉死，再跑第四批。这次ID后四位稳定了，可复现性回来了。但代价是：如果跑批跨过校时窗口，ID又会跳。所以这不是解法，只是验证手段。

三是把批次ID拆成两段——稳定段用语料哈希加盐版本号拼，时间段单独挂一个字段，只做审计、不参与主键。这样ID可复现，时间也留痕。

顺带说一句，分母口径也得跟着改。以前按批次ID去重，时钟一抖，同一批数据被拆成两个ID，分母就虚高。我重新按稳定段聚合，同一批的量直接降下来了。这种虚高的分母换曝光，我不认。

还有个细节：校时窗口尽量避开跑批启动的瞬间。我现在的做法是跑批前先等一次同步完成，确认偏移在阈值内再放行。

这个问题不大，但会一直啃你的账。我想问的是：你们系统的批次ID，到底是跑前写死的、还是跑的时候现拼的？如果是现拼的，里面有没有混进时间成分？有的话，你们是怎么保证同一份输入跨天可复现的？