站长工具：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f1cb946eeb79.html
📄
站长工具：脚本调用工具遇到限流时怎样保护已有结果
遇到限流时，最该保护的不是“继续跑完”，而是已经拿到的结果和已消耗的调用预算。判断依据是限流是否可恢复、结果是否可增量合并。若限流来自短时配额，暂停并保存进度即可；若来自账号或权限层面的硬限制，继续重试只会浪费更多时间。一个可执行动作是：在脚本里把每次成功返回先写入本地文件，再决定是否重试，这样下一步可以只补缺失部分，而不是整批重来。
先分清两种限流：配额型与策略型
配额型限流通常表现为一段时间内请求数超限，等待后同一接口可能恢复。策略型限流则常见于触发风控、权限不足或接口口径变化，重试间隔再长也可能持续失败。区分方法是记录每次失败的时间、返回状态和请求参数：如果失败集中在某个时间窗，且窗口过后同一参数能成功，更接近配额型；如果同一参数在任何时间都失败，而其他参数正常，更接近策略型或参数问题。
这一步的结果直接决定下一步：配额型适合保留断点并延迟重试，策略型应先停止批量调用，改为人工核对参数或权限，避免把剩余额度耗在无效请求上。
两种保护做法：断点续跑与先冻结再合并
断点续跑适合任务可拆分、每条记录有唯一标识的情况。做法是把成功结果追加写入，并单独记录已完成标识；下次运行只请求未完成部分。代价是需要维护状态文件，脚本复杂度上升，且要防止重复写入。
先冻结再合并适合任务量不大、或结果之间需要整体校验的情况。做法是立即停止请求，把当前结果原样保存为一份快照，再离线检查缺失范围。代价是可能暂时无法得到完整结果，但能避免在限流期间产生半成品数据。
选择条件可以这样判断：如果缺失部分可以独立补齐，断点续跑更省调用；如果缺失部分会影响整体统计口径，先冻结更稳妥。
能区分两种解释的证据
- 失败是否与请求频率相关：降低频率后恢复，倾向配额型；不恢复，倾向策略型。
- 失败是否与特定参数相关：换参数成功，说明问题在参数或权限，不在总量。
- 失败是否与账号状态相关：同一脚本换环境仍失败，应核对账号或凭据状态。
- 结果是否可增量合并：有唯一标识且字段稳定，才适合断点续跑。
这些证据要同时看，不能只凭一次失败就断定原因。请求量下降或某次抓取归零，也可能只是任务已完成、参数写错或接口返回结构变化，不能单独作为处理正确的证明。
一个注明假设的短例子
假设脚本需要查询 500 个目标，已成功返回 180 个后开始连续失败。若日志显示失败集中在两分钟内，且等待后同一目标可以成功，可以先保存这 180 条，再用 completed_ids 记录已成功标识，下一轮只请求剩余目标。若等待后同一目标仍失败，而换一个已知正常的目标能成功，则应先检查参数和权限，不要继续重试剩余目标。这个例子的数字只用于说明比较方法，不代表任何真实工具的表现。
执行保存动作后，下一步应验证保存文件是否完整、字段是否一致，再决定重试范围。若文件本身缺失或字段错位，断点续跑会放大错误，此时先冻结更合适。
把保护动作写进脚本的最低要求
至少做到三点：成功结果先落盘再发下一个请求；失败原因分类记录，不把所有失败都当成同一类；重试前先读取已完成标识并跳过。这样限流发生时，已有结果不会因为进程中断而丢失，后续也能把重试范围缩小到真正缺失的部分。具体工具的重试参数、配额口径和返回字段需要以实际文档和当前返回为准，不能凭通用经验直接套用。
