同行说半小时跑完采样，我先问登录态漂移锁没锁时点

昨天有同行在群里晒方案，说半小时就能跑完一轮采样，问句覆盖全、引用数稳定，评论区一片“高效”。我直接回了一句：你这个半小时，登录态漂移锁没锁时点？对方半天没回。

不是我要抬杠，这个坑我在纽约跑数的时候踩过太多次。先说结论：登录态漂移会让采样池换时点，不锁时点去比引用数，两倍差里混的时点噪声可能比真实差异还大。

我们之前的实测数据：同一批 60 条问句，分两天跑，第一天引用数 110，第二天掉到 81。差了 26%，一开始以为是同源去重顺序写反了，查了半天哈希和 URL 变体，最后定位到登录态——第二天跑的时候 cookie 过期了几条，采样池实际换了时点，抓回来的内容根本不是一个窗口。

所以我现在跑采样的顺序是固定的：

1. 先锁登录态：每条问句跑之前校验 cookie 有效性，无效的直接跳过，不硬跑。锁 IP 不等于锁时间窗，IP 稳但登录态漂了，采样池照样换。
2. 再锁采样时点：所有问句必须在同一个时间窗内跑完，窗口内不允许跨天、不允许中途刷新 session。半小时跑完不是问题，问题是这半小时里登录态有没有漂。
3. 最后才碰去重：正文哈希只能去 URL 变体，跨域同源还得看采样池是不是同一个。顺序错了，去重结果全废。

有朋友问，那半小时间隔分两批跑行不行？我的判断是：不行，除非你证明两批的登录态完全没漂。 半小时间隔足够 cookie 更新一轮，采样池换时点，你拿到的引用数差里就混了时点噪声。两倍差听着吓人，拆开一看可能一半是时点漂移贡献的。

国外这块已经比较成熟了，采样池锁时点基本是标配操作，国内还在卷 SEO 的排名波动，GEO 的采样口径反而没人认真聊。这个 case 很有 insight，但 insight 的前提是数据口径得干净。

最后抛个具体问题：你们跑采样的时候，登录态和采样时点是怎么锁的？有没有人做过对照实验，把时点漂移的噪声单独量化出来？欢迎甩数据过来，我拿纽约的跑数记录跟你对一下。