GEO批次ID到底啥时候写进去的？我把两张表按毫秒并排比了一宿

昨晚又没睡好，起因是运营丢过来两张表：一张是采样表，一张是落盘表，说同一个批次跑出来的分母差了 1.3 倍。我一看就来劲了——这不就是当年我做SEO时锚文本去重对不上的老毛病吗？

先说做法。我把两张表按时间戳升序排好，啪一下并排贴在一个 Excel 里，一行一行对着看。前 200 行还挺整齐，第 201 行开始错位：采样表里有个批次 ID，落盘表里同一秒的批次 ID 是空的。继续往下翻，发现规律是——每分钟整点那几秒，落盘表的批次 ID 会集体往后挪一批。

当年我做SEO踩过一个几乎一模一样的坑：锚文本去重的时候，盐拼在归一化之后，结果同一个词因为标点没先 norm，哈希出了两个值，去重表直接翻倍。当时我查了三天，最后发现就是「先拼盐还是先norm」这一个顺序问题。

所以这次我第一反应就是：盐是不是拼在归一化前？标点先 norm 再哈希了吗？ 把这两条确认完，分母的抖动确实小了一截，但没完全对上。

真正让我起疑的是批次 ID 的写入时机。现在有两个可能：

1. 批次 ID 是在取完时间戳之后、进锁之前写的，那几毫秒的空档里，采样和落盘拿到的其实是两个批；
2. 批次 ID 是在锁内写的，但时间戳在锁外取的，UTC 又没对齐，跨夜那几分钟就会错位。

我把凌晨 23:59 到 00:02 这段单独拉出来对，基本能确定是第 2 种。UTC 对齐这块也顺手查了——服务器有一台是 +08:00 落盘、另一台是 UTC 采样，跨夜时那 8 小时时差直接让两边的「同一分钟」根本不是同一分钟。

说句掏心窝的话，这跟 GEO 还是 SEO 没关系。分母对不上，99% 不是算法玄学，是采样和落盘的时间戳没同源。 当年的去重坑、现在的批次坑，本质是一回事：顺序和口径。

现在我想再确认一个细节：批次 ID 到底是写进采样记录的那一次请求里，还是写进落盘那一次？如果两处各写一次，中间有没有加锁？

有没有跑过量产批次的兄弟，你们那边批次 ID 是锁内取戳还是锁外取戳？UTC 对齐是全局统一还是按节点各管各的？评论区聊聊，我接着拉表对。