给GEO批次设计幂等键时，我把采样戳和落盘戳都试了一遍，两张表差出17条记录

上周给一个客户的GEO跑批链路做重构，卡在幂等键到底该用哪个时间戳上。这个问题看着小，但直接决定了分母能不能对齐，也是我这段时间一直在追的批次幂等键设计里最绕的一环。

先说背景。客户那边每天跑两批GEO问句，一批早上9点，一批凌晨2点，走的是同一套问句模板。问题出在重跑机制上：只要某一批中途失败，运维会重新触发，但两次触发之间系统会生成新的批次ID。结果就是同一个逻辑批次在库里有两条记录，一条是原始失败的，一条是重跑成功的。

我一开始想得很简单，拿采样时间戳当幂等键——因为采样是链路的第一步，理论上同一次采样只会发生一次。根据我的模型，这样去重应该能把重复记录压到零。但实际跑下来，原始失败那条和重跑那条的采样戳差了17秒，系统判定成两个不同批次，没被去重掉。17秒哪来的？我翻了日志，是第一次触发时采样服务拿了一次系统时间，失败后重跑又拿了一次，中间隔了运维手动确认的十几秒。

后来我换成落盘时间戳当幂等键。逻辑上更接近“这条数据到底有没有落成”，但问题反过来了：落盘戳是批量写入时统一赋的，同一批里几千条记录共用同一个落盘戳，粒度太粗，跨批重跑时反而把本该保留的两条不同逻辑批次的记录给合并了。我拿三天的日志对了一下，落盘戳方案比采样戳方案少了17条有效记录，全是被误合并的。

这两天我试了个折中方案：幂等键用“问句模板ID + 业务日期 + 批次序号”拼，不依赖任何时间戳。时间戳只作为辅助字段存着，用来做时间锚点校准，不参与去重。跑了两天，重复记录归零，误合并也没再出现。

但我心里还是不踏实。这个方案的前提是批次序号在重跑时能保持一致，而序号目前是运维手工填的，没有系统层面的强制约束。等于说我把幂等性从系统保证挪到了流程保证上，长期看是有风险的。

所以想问问社区里做过GEO跑批幂等设计的，你们是拿什么当键的？有没有人试过用采样戳加业务ID的组合，而不是纯时间戳？另外批次序号这种手工字段，你们是怎么做强制校验的？