GEO试跑批次ID写太晚，我白跑了两周问句

上周复盘跑批日志，发现一个低级但巨亏的坑：批次ID写入时间点没锁死，导致两周的问句实验数据全部作废。

场景：我们跑GEO问句表，每批500条，一天两批。为了效率，我让开发把批次ID生成放在「问句入队后」——听起来没问题对吧？但实际执行时，问句入队和批次ID写入之间隔了平均3-7秒。这期间如果采样戳（timestamp）已经打了，后面批次ID再写进去，日志里就会出现「同一采样戳对应两个批次」的脏数据。

判断依据：我翻了2000条日志，发现有12%的记录批次ID晚于采样戳超过2秒，这部分数据在归因时全部得丢掉。更坑的是，因为批次ID是异步写入，我们做分母去重时根本没法按批次聚合——你都不知道这条问句到底属于哪一批。

踩坑细节：一开始我以为是采样戳精度问题，换成毫秒级后还是对不上。后来现场读加锁日志才定位到：批次ID的生成逻辑在消息队列里被延迟了。改法很简单——在问句入队前先生成批次ID并写进消息头，后面所有环节只读不改。改完后跑了一周，脏数据从12%降到0.3%。

结论：GEO快速迭代没错，但试跑前必须把批次ID的写入时机锁死。宁可多花半小时写个前置校验，也别让两周的数据打水漂。我的做法是：试跑前先跑10条空批次，检查采样戳和批次ID的时序偏差，超过500ms就报警。

你们跑GEO实验时，批次ID是在哪一步写入的？有没有遇到过类似的异步坑？