谷歌权重查询：脚本被限流时先保住旧结果还是重跑
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9f68234c8b9a.html
📄
谷歌权重查询：脚本被限流时先保住旧结果还是重跑
先保住已有结果，再决定是否重跑。脚本调用第三方谷歌权重查询工具时，限流通常表现为请求被拒、返回空值或长时间等待。此时最危险的动作是让脚本从头重试，因为新请求会覆盖或冲掉已经拿到的旧数据。正确顺序是：把本轮已成功返回的记录落盘并标记为“待确认”，暂停后续请求，再根据失败比例和这批数据的用途，选择“只补缺口”或“整批作废重跑”。
先判断限流影响的是哪一层
限流可能来自工具服务端，也可能来自你自己的出口IP、账号配额或本地并发设置。三种情况的处理方式不同，先看证据再动手：
- 整批请求几乎同时失败：更可能是出口IP或账号级配额触顶，重跑同样会失败，应改为降低并发或错峰。
- 只有部分域名或部分批次失败：更可能是单次请求内容触发了服务端保护，保留成功部分、只补失败项更划算。
- 失败前响应时间明显变长：说明已经接近阈值，继续重试只会扩大损失，应立即停止并落盘。
注意，请求量归零或返回空值不能单独证明限流已经解除，也可能是接口变更、字段调整或网络中断。要结合错误码、响应头和重试后的表现一起判断。
条件一：旧结果仍可复用时，只补缺口
如果这批谷歌权重查询结果用于内部排查、趋势对比，且失败项占比不高，优先保留旧结果。具体动作是：
- 把已成功的记录写入带时间戳的文件，字段包含查询对象、返回值、抓取时间。
- 单独生成一份失败清单，只记录未返回的查询对象，不要覆盖原文件。
- 等待一段时间后，只对失败清单发起请求，并发数降到原来的三分之一左右。
- 补跑完成后，用查询对象做一次合并，检查是否有重复或冲突记录。
这个动作的结果会直接决定下一步：如果补跑后失败项仍大量存在，说明限流没有缓解，应停止补跑并转为人工抽查；如果补跑顺利，则可以继续处理下一批，但仍要保留失败清单作为审计依据。
条件二：旧结果已过期或口径变化时，整批重跑
如果旧结果对应的工具指标定义已经调整，或者这批数据要用于对外交付，部分保留反而会制造不一致。此时应把旧文件归档而不是删除，然后整批重跑。重跑前先做两件事：把并发和频率降到保守值，并给每个请求加上可识别的批次标记。这样即使再次被限流，也能快速定位是哪一批出的问题，而不是把全部结果混在一起。
例外情况是：如果旧结果已经用于某个已交付的结论，重跑后新旧数据不一致，不要直接覆盖，应保留两个版本并注明抓取时间，由使用方决定采用哪一版。
落盘策略比重试次数更重要
很多脚本把结果放在内存里，直到全部跑完才写文件，一旦限流就全部丢失。更稳妥的做法是每成功一条就追加写入，或者每处理固定数量就落盘一次。写入时使用append模式，避免中途失败把已有内容截断。
假设一个脚本需要查询两百个对象，跑到第一百二十个时开始被限流。如果采用逐条落盘，你至少保住了一百一十九条；如果采用最后统一写入，可能一条都不剩。这个对比说明的是落盘频率对结果保全的影响，不代表任何具体工具的配额或阈值。
恢复请求前先确认限流原因是否消失
限流缓解后不要立刻恢复原并发。先用少量请求试探，观察是否稳定返回，再逐步提高。如果试探请求仍然失败，继续等待或更换出口，而不是加大重试次数。重试次数增加只会让服务端更确定你在高频调用，可能延长限制时间。
最后，把这次限流的失败清单、落盘文件和恢复后的补跑记录一起留存。下次再遇到类似情况，可以直接复用这套“先落盘、再补缺口、最后决定是否重跑”的流程，而不必从零判断。
