当年做SEO看日志时间戳，现在GEO批次ID我也在抠这个

当年我做SEO的时候，判断一个爬虫是不是真来过，就看服务器日志里的时间戳，秒级不够，得毫秒。现在做GEO，后台给的那个批次ID，我总觉得写法有猫腻，最近又抠上了。

先说我发现的一个现象。同一个品牌词，连续跑了三批GEO，引用率分别是4.1%、4.3%、3.9%。按常理，波动这么小应该算稳定。但我把每批的批次ID导出来，用免费表格按毫秒排了个序，发现一件怪事：批次ID里的时间片段，和后台日志里的“批次开始时间”对不上，差个几十毫秒到几百毫秒不等。

这就有意思了。当年我们做锚文本去重，也遇到过类似的事——去重逻辑写在归一化之前还是之后，结果能差出三成。那时候我踩过的坑是：标点没norm就直接哈希，导致“SEO优化”和“SEO优化。”被当成两个词。现在GEO这个批次ID，我怀疑也是同一个路子：盐拼在归一化前还是后，哈希输入的字段顺序怎么排，都会影响最后那个ID长什么样。

更具体地说，我盯的是两个时间戳：一个是采样时间戳，一个是落盘时间戳。采样戳是系统决定“这批数据要了”的时刻，落盘戳是数据真正写进库的时刻。如果批次ID用的是采样戳，那它代表的是“决定跑批”的瞬间；如果用落盘戳，代表的是“跑完存下”的瞬间。这俩差多少，取决于系统队列堵不堵。

我拿自己家三天跑批的数据做了个粗糙的对照。第一天队列空，两个戳差0.7秒；第二天有别的任务插进来，差到11秒；第三天我把并发调低，又回到0.02秒。关键来了：批次ID里的时间片段，跟采样戳的毫秒位对齐，跟落盘戳对不上。也就是说，这个ID是采样时刻就写死的，不是跑完才拼的。

那问题就转到了锁内外。如果写ID的操作在采样锁里面，那它拿到的就是采样那一刻的精确时间；如果锁在外面，中间隔了个队列等待，ID里的时间就会跳。我目前的判断是：它大概率在锁内取的戳，但取的可能是UTC，不是本地时间。因为我发现凌晨跑批的ID，小时位换算成UTC正好对得上。

当年做SEO，我们看日志时间戳也吃过亏，服务器时区没统一，导致抓取频次算错。现在GEO这套东西，核心还是这个理：时间戳同不同源，决定你后面所有归因能不能信。批次ID要是采样戳和落盘戳混着用，那引用率按批次拆，分母就是歪的。

我把两张表并排摆了一宿，眼睛都花了，还是没敢下结论。就想问一句：你们跑GEO的时候，有没有人专门对过批次ID里的时间片段和采样戳的毫秒位？是取锁内还是锁外？UTC对齐了吗？