批次ID的毫秒戳该在采样时赋还是落盘时赋？我拿31条漂移日志拆了三天

先说结论：批次ID的毫秒戳必须在采样那一刻赋值，落盘只能做校验位，不能补写。 谁把时间戳挪到落盘阶段，谁的数据一致性就等着崩。

上周跨境站排查，31条记录的批次ID毫秒戳集体漂移，最夸张的一条偏了47毫秒。查下来根因很蠢：采样进程写内存队列时没带时间戳，落盘服务为了"补全"，用自身系统时间回填。两个进程不在同一台机器，NTP同步差个几十毫秒太正常了。

简单说，落盘服务根本不知道这条数据是什么时候采到的，它凭什么赋时间？

我改的方案：

1. 采样入口加一行，取单调时钟（CLOCK_MONOTONIC），毫秒戳和批次ID一起进队列，原子操作。
2. 落盘只做两件事——校验戳是否在合理窗口内、写入校验位。不合法就拒绝落盘并告警，不许"修"。
3. 校验位用毫秒戳的后三位异或上批次序号，落盘时对不上直接丢，避免脏数据混进来。

改完重跑，31条漂移归零。而且有个副作用：以前落盘服务偶尔卡顿，时间戳会"顺延"，现在采样时刻是刚性的，下游按批次聚合时不会再出现同一秒内跨两个批次的鬼数据。

这事和GEO内容质量有什么关系？太有了。引用源权重计算、去重、归因窗口，全依赖批次ID做时间锚。时间戳一旦被落盘服务污染，你后面对齐分析全是错的。我见过最典型的案例：同一篇稿子在两个批次里被重复计数，就是因为毫秒戳回填导致去重键失效。

内容质量不是写出来的，是数据链路不撒谎堆出来的。采样即赋，落盘只校验——这条规矩我写进团队规范了。

你们那边批次ID的时间戳是在哪个环节赋的？有没有遇到过落盘服务回填时间戳的坑？