GEO 批次 ID 的毫秒戳，我要求采样时就赋，落盘只做校验位

简单说，批次 ID 的毫秒戳赋值时机，比哈希盐值放哪还容易出事。

上周复盘一条跨境站的引用源权重曲线，31 条记录整体漂移。我先没看权重，先去看批次 ID。结果发现那批任务的毫秒戳是在落盘时才生成的——也就是说，采样机采完一条，先攒在内存队列里，等存储机批量写库时才打时间戳。中间隔着 40 秒到 3 分钟不等的队列延迟。

方向反了。毫秒戳必须在采样时刻就赋，落盘只做校验位。

为什么。因为批次 ID 是你后续所有归因的锚点。引用源权重、异常率、分母口径，全都要按批次切。如果时间戳代表的不是“这条数据是什么时候被采到的”，而是“什么时候被写进去的”，那跨机器、跨队列的批次就会自然错位。我们那 31 条漂移里，有 19 条是采样机时钟比存储机慢了 47 秒，落盘时间戳反而更早，批次顺序整个乱了。

排查路径我固定成三步：

1. 先对表。 采样机和存储机是否同源校时？我们用免费 NTP，跑前强制 sync，偏差超过 50ms 直接判批无效。
2. 再看赋值点。 时间戳生成在采样函数里，还是写库函数里？如果是后者，队列延迟就是你的系统误差。
3. 最后看跳变。 同一批次内相邻两条时间戳如果出现负跳变，基本可以确定赋值点错了。

改完之后，那 31 条漂移收敛到 4 条，权重曲线也稳了。

顺便说个连带影响。品牌知识库更新后，引用源权重从 0.78 掉到 0.41，我一开始以为是内容质量降了，后来发现是批次错位导致部分引用被归到了上一个批次，权重分母算错了。内容没动，权重却变了——这种时候先查时间源，别急着改内容。

GEO 的技术门槛真不高，但时间戳这种地基没打对，上面盖什么都是歪的。

想问一句：你们跑批的毫秒戳，是在采样函数里生成的，还是在写库那一步补的？有没有人跟我一样踩过队列延迟的坑？