TTFB 1.4秒就踩线了？纽约抓取队列约1.2秒，别再只盯着盐前缀

刚在纽约跟完一轮 GEO 批次，回来发现群里还在争盐前缀、回填、时区开关。这就像车都撞了，还在讨论车标贴没贴正。

先放实测。我们同一批 query 分两组跑，内容页结构一样，唯一变量是 TTFB：A 组稳定 0.6-0.8 秒，B 组压在 1.4 秒附近。跑满 3 个批次，每批样本 5,000 条，引用率 A 组 18.7%，B 组 11.2%。分母用的是批次内有效返回数，不是请求数。B 组不是内容差，是抓取队列等不起。

纽约节点这边，抓取队列的软阈值大概在 1.2 秒。什么意思？TTFB 超过 1.2 秒，你的 URL 在队列里就开始被降权，不是不抓，是排到后面。排到后面，同一批次时间窗关掉，你这条内容就没进分母。很多人看引用率掉，第一反应是盐版本号写错了，其实盐错了是全批崩，不会只崩一部分。

我的做法很土但有用。

第一，先锁物理时钟。跑批机强制 NTP 校时，偏差超 50ms 直接踢出采样。别笑，我们真有过一台机器慢 8 秒，批次的 time bucket 全错位，分母直接虚高 23%。

第二，把 TTFB 当成批次准入指标。每次跑批前，先打 200 条探针，P95 超过 1.2 秒就推迟批次，别硬跑。硬跑出来的引用率没有统计意义。

第三，分母要写清楚是「批次有效返回」还是「原始请求」。这两个口径差 30% 以上，我跟国内团队对齐口径就花了三天。

有人说国内网络环境不一样，不能直接套纽约阈值。对，所以我没让你照搬 1.2 秒，我是让你去测你自己的降权线。做法：把 TTFB 从 0.4 秒到 2.0 秒切成 8 档，每档固定 1,000 条 URL，跑同一个批次，看引用率拐点在哪。拐点就是你的线。

我现在的判断顺序：物理时钟 -> 批次分母口径 -> TTFB 降权线 -> 最后才看盐和 ID。反过来查，全是噪音。

你们有没有测过自己节点的 TTFB 拐点？是 1.0 秒还是 1.6 秒？还是说你们压根没把队列等待算进批次耗时里？