谷歌权重工具，脚本调用限流后怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fb086ca087ce.html
📄
谷歌权重工具，脚本调用限流后怎样保护已有结果
限流发生时，第一件该做的事不是重试，而是把已经拿到的结果落盘并标记数据边界。脚本被限流后，内存里的响应会随进程结束消失，而分页游标、请求参数和已完成批次如果不落盘，后续无法判断哪些数据可信、哪些需要补。先固化已有结果，再决定冷却后继续还是换路径，能避免整批重跑。
限流的两种成因，决定你该停还是该换
同样是返回限流错误，背后的条件不一样，处理方式也不同。可以用一个简单判据区分：
- 配额型限流：错误信息里出现配额、速率或每日上限字样，且重置时间可读。此时等待即可恢复，已有结果完整，冷却后从断点续跑。
- 行为型限流：连续请求被拒但无明确配额提示，或同一脚本换出口后仍被拒。此时等待未必有效，可能是请求模式被识别，需要降速、拆分或换数据来源。
两种成因的区分依据是错误响应本身，不是请求次数。有些工具在接近上限时先返回部分数据再报错，这类响应必须视为不完整，不能直接并入结果集。
落盘时保留三样东西，结果才可复用
只把最终结果写入文件是不够的。限流中断后要继续，至少需要保留：
- 已完成批次的原始响应，而不是清洗后的汇总值。清洗逻辑可能有问题，原始响应可重放。
- 请求参数与分页游标，包括查询词、时间范围、偏移量。没有这些，续跑无法对齐。
- 中断时的错误响应原文，用于判断限流类型和冷却时长。
一个假设的例子：脚本按关键词分批查询，跑到第 7 批被限流。如果只保存了前 6 批的结果，没有保存第 7 批的请求参数，那么冷却后要么从头重跑，要么凭记忆重建参数，两者都会引入偏差。落盘后先写一个标记文件记录中断位置，再启动冷却计时，这一步做完，后续选择才有依据。
缺少完整数据时，先做可执行的最小动作
如果你没有完整配额、没有历史调用记录，也不掌握工具的全部权限，仍然可以做两件事：
- 把已获得的结果按批次编号存档，每批附带请求参数和抓取时间戳，形成可追溯的片段集。
- 对未完成部分只记录待办参数，不猜测缺失值。
这样做的结果是：你手里有一份边界清晰的部分数据，可以用于内部核对口径，但不能用于得出总量结论。需要明确的是，部分数据不能推出整体分布，抓取量归零也不能单独证明脚本被永久封禁——可能是临时冷却、参数错误或网络中断。这些解释需要靠错误响应原文区分，不能靠现象本身下结论。
冷却后继续还是换路径，看这两个条件
冷却结束后，选择取决于两个可验证的条件：
条件一：错误响应是否给出明确重置时间。给出重置时间且时间已过，优先从断点续跑，因为已有结果的参数口径一致，拼接后偏差最小。没有重置时间，先发一个探测请求，观察是否仍被拒，再决定。
条件二：剩余数据量是否值得继续。如果剩余批次远多于已完成批次，且限流反复出现，继续在同一路径上消耗冷却周期，收益低于换一个数据来源或降低请求频率。此时把已有片段作为基线，换路径后对齐字段再合并。
例外情况：如果已有结果本身是抽样而非全量，续跑拼接会混合两种抽样口径，这种情况下宁可重跑，也不要把不同口径的数据合并交付。
把结果交给下一步之前，先标注可信范围
存档完成后，在结果文件旁附一段说明：已完成批次、缺失批次、中断原因、冷却后是否验证。这段说明决定了下一步动作——是直接用于内部分析，还是需要补数后才能对外使用。限流不是数据作废的理由，但未标注边界的结果被当作完整数据使用，才是真正的风险来源。
