站长实用软件，脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /29401c2ab673.html
📄
站长实用软件，脚本调用工具遇到限流时怎样保护已有结果
先保住已经拿到的结果，再决定是否继续调用。限流发生时，最危险的动作往往不是停下，而是让脚本带着不完整状态反复重试，最后把可用的部分结果覆盖或混入失败数据。保留、改写或退出这三条路各有前提，判断依据是：已有结果是否完整到可交付、限流是短暂还是持续、以及重试是否会改变结果的含义。
先判断已有结果是“完整批次”还是“半成品”
保护结果的第一步不是改脚本，而是确认手上这批数据处于什么状态。如果一次调用返回的是一批可独立使用的记录，例如一批页面标题、一批链接状态，那么限流只影响后续批次，已落盘的部分就是完整批次，值得原样保留。反过来，如果一次结果需要多次调用拼装成一条记录，比如分页抓取一个列表再合并，那么中途限流意味着这条记录是半成品，直接保留会得到一个看似正常、实际缺字段的条目。
可核对的证据是落盘文件里的字段完整度和批次边界。假设一个脚本每批写 50 条记录，日志显示第 3 批只写入 17 条就触发了限流，那么前两批共 100 条可视为完整批次，第 3 批的 17 条需要标记为不完整，而不是当作正常数据混入。这个动作直接影响下一步：只有能区分完整与不完整的批次，后面的重试才有明确的起点。
保留：适合限流短暂且结果可增量拼接的情况
当限流表现为短时间拒绝、稍后恢复，且每次调用返回的是互相独立的记录时，保留已有结果并记录断点是最省成本的选择。前提是脚本本身支持幂等写入，也就是同一条记录重复写入不会产生重复行或覆盖错误值。判断方法很简单：检查写入逻辑是否带唯一键或去重条件，而不是无脑追加。
具体动作是先把断点写进一个独立的状态文件，内容至少包括最后成功批次的标识和已完成条数，再让重试从断点之后开始。这样做的影响是：即使重试再次被限流，已有结果的边界依然清晰，不会因为反复从头调用而让日志和文件越滚越乱。需要说明的是，限流恢复时间无法从单次拒绝推断，短时恢复只是假设，实际是否恢复要以后续调用的响应为准。
改写：限流持续但结果仍值得补齐时，降低调用强度
如果限流反复出现、间隔没有明显规律，而任务本身没有紧迫到必须立刻完成，可以考虑改写调用方式，而不是直接放弃。常见的改法包括拉长调用间隔、减少单次请求的数据量、把一次大批量拆成多次小批量。这些改法不改变结果的语义，只是让脚本更慢、更温和地推进。
这里要避免一个直觉陷阱：调用量下降、返回变少，并不自动说明限流策略变严，也可能是本地网络波动、目标端临时负载变化或脚本自身超时设置改变。要区分这些解释，可以对照同一时间段的响应状态码分布和失败位置；如果失败集中在固定批次，更可能是调用节奏问题，如果失败位置随机，则要考虑网络或目标端波动。改写的代价是时间变长，所以它适合结果可延后交付的场景，不适合当天必须出结论的任务。
退出：结果无法补齐或重试会污染已有数据时
有些情况下最合理的动作是停止脚本，把已有结果封存。触发退出的条件通常有两个：一是半成品记录无法通过补调恢复，比如目标端已经不再返回同一分页；二是重试逻辑会覆盖或追加到已有文件，导致完整批次和不完整批次混在一起，事后无法分辨。此时继续调用的收益低于把数据弄脏的风险。
退出的具体动作是给当前结果打上时间戳和状态标记，把不完整部分单独存放，不并入主结果。这样做的结果是，后续无论是人工补录还是换时间重跑，都有一个干净的基线可以对照，而不是在一堆来源不明的数据里反复排查。
用一个短例说明取舍怎么落到操作上
假设一个脚本要采集 200 个页面的状态，每批 20 个，写到第 6 批时开始被限流，此时已完整写入 100 个，第 6 批只写了一半。可以这样处理：把前 100 个标记为完整结果并保留，把第 6 批的 10 个单独存放并标记不完整，状态文件记录断点在第 5 批之后。然后根据限流是否在短时间内缓解，决定是从第 6 批重新调用，还是直接退出、改用更慢的节奏另起一轮。这个例子里没有真实数据，只是说明判断顺序：先分完整与不完整，再决定保留、改写还是退出。
无论选哪条路，都要让状态文件和结果文件分离，并保证重试不会静默覆盖已有内容。限流本身不是结果错误的证据，它只说明调用节奏需要调整；真正决定结果能不能用的，是批次边界是否清楚、写入是否可去重、以及重试是否会改变原有数据的含义。
