旺道优化，脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0181a1897879.html
📄
旺道优化，脚本调用工具遇到限流时怎样保护已有结果
能保住已有结果的前提，是脚本把每次调用结果先落到本地，再决定是否继续请求；如果结果只保存在内存或远端会话里，限流发生后往往无法完整取回。最小动作是立即停止重试、保存当前批次和游标，并从最后一次成功落盘的记录继续。这个结论只在工具仍允许读取历史结果或本地已有缓存时成立；若限流同时切断了结果读取权限，本地又没有落盘，就不能假设稍后一定能补齐。
先判断限流影响的是提交还是取回
脚本调用工具时，限流可能发生在两个不同环节：一是发起新查询或新任务被拒，二是读取已有任务结果被拒。两者的保护动作不同。前者只需暂停新增请求，保留已提交任务的标识；后者则要在本地寻找已经取回的部分，避免覆盖。
可区分的证据包括：响应中是否仍返回任务编号、是否还能按编号取回旧结果、错误是出现在提交接口还是查询接口。若提交被拒但查询仍可用，优先把已提交任务的结果取回；若两者都被拒，只能保存请求参数、游标和本地已有数据，等待限制解除后再续。不能因为一次请求失败就判断账号被封或数据已丢失，限流、权限变化和临时故障都可能产生相似现象。
最小保护动作：落盘、标记、停重试
缺少完整数据或权限时，仍可执行的最小动作有三步：
- 把当前批次结果写入独立文件，文件名带批次标识和游标，不覆盖上一批。
- 在进度记录中标记最后成功的记录位置、请求参数和时间，不写推测性的完成状态。
- 关闭自动重试或把重试次数降为零，避免继续消耗限额并制造重复任务。
假设一个脚本按页取回结果，第 7 页成功、第 8 页被限流。若第 7 页已落盘，下一步是从第 8 页游标继续；若第 7 页只在内存中，重启后只能从第 6 页或更早位置重取，并需要去重。这个例子的数字仅用于说明游标与落盘的关系，不代表任何工具的实际分页规模。
哪些做法会让已有结果反而丢失
最常见的破坏性动作是限流后继续高频重试，并把新响应直接覆盖旧文件。另一个是清空本地缓存再重新拉取，结果在限制解除前既没有旧数据也没有新数据。还有一种是把未完成批次标记为完成，后续执行人员会跳过补取。
会使前述结论失效的反例是：工具的结果只在远端短期保留，本地又没有及时取回，且限流期间无法读取历史结果。此时“保存游标等待续取”并不能保护结果，因为远端结果可能已不可访问。遇到这种情况，应把重点转向记录已提交任务的标识和参数，并核对工具是否提供结果导出或保留期说明；具体保留规则需要以该工具的当前文档或实际返回为准，不能凭经验断言。
限流解除后的下一步动作
先做一次小范围探测：用单个请求确认读取权限和限额是否恢复，再决定是否继续批量调用。若探测成功，从最后成功游标继续，并把新结果写入新文件；若探测仍失败，不要扩大重试范围，转为人工核对已落盘部分，列出缺失区间。
对已有结果做一次完整性检查：记录条数、关键字段是否为空、批次之间是否有重复。检查结果决定下一步是补取、去重还是重新提交。若缺失区间集中在少数批次，可优先补取；若缺失范围无法确定，应保留现有文件并标注不确定状态，而不是用一次全量重跑覆盖。
最后把处理过程写成简短记录：限流发生时间、最后成功位置、已执行动作、仍未确认的事项。这样即使换人接手，也能从已知边界继续，而不必重新猜测哪些结果可信。
