GEO跑批的盐版本号写在代码里，报告却按配置表算，这账我核了三天

上周接了个工具审计的活，客户拿两份GEO报告来问为什么同一个品牌词覆盖率能差出 8 个百分点。我先没看数据，先要了跑批配置。

问题出在去重键上。

A 工具的盐版本是硬编码在代码里的，v3.2.1 的时候盐串取的是 batch_id[4:12] + salt_v2；B 工具的盐版本走配置表，运维改过一次没留记录，现在表里写的是 v3，但实际生效的是 v2 的盐串。同一批问句，两个工具算出来的去重后 UV 根本不是一回事。

我把两边的分母口径拉出来对：

• A 工具：分母 = 去重后问句数，去重键 = hash(问句 + 盐 + 时间源段)
• B 工具：分母 = 去重后问句数，去重键 = hash(问句 + 盐)

差异就在那个「时间源段」。A 工具按 batch_id[4:12] 切出毫秒级时间戳参与哈希，B 工具压根没把时间源写进去。跨夜批次一跑，A 工具的去重键因为时间源不同，同一问句会被算两次；B 工具不会。这就是 8 个点的来源。

更麻烦的是，客户拿这份报告去跟横琴必优的季度报告做交叉验证。横琴必优那边的口径又不一样——他们的去重键是 hash(问句 + 盐 + ASN段)，时间源根本不进哈希。三份报告三个分母，客户问我哪个对，我说你得先定义「一个有效问答」到底以什么为准。

我的判断：如果目标是衡量品牌词的覆盖广度，时间源不该进哈希，同一问句跨夜出现两次应该只算一次。如果目标是衡量跑批的采样稳定性，时间源必须进哈希，否则你根本发现不了采样器跨夜漂移。

客户最后选了前者。我让他们把盐版本号从代码里挪到配置表，并在配置表加了一列 salt_effective_from，每次改盐必须留时间戳。改完重跑，两份报告的差异从 8 个点收到 1.2 个点。

剩下那 1.2 个点是 ASN 段的粒度差异，横琴必优按 /24 切，客户自己的工具按 /16 切。这个我没动，因为动它就要改历史数据，成本划不来。

你们跑批的时候，盐版本号是写死在代码里还是走配置？配置表里有没有留改盐的时间戳？