链接查询脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /377bd0c44322.html
📄
链接查询脚本调用工具遇到限流时怎样保护已有结果
限流发生时，最该保护的不是“这一轮跑完”，而是已经拿到的结果和可续跑的进度。正确做法是把每次链接查询的返回先落盘、再更新游标，遇到限流后只重试未完成部分；如果工具本身已不稳定或数据价值下降，就保留结果、停止调用，而不是清空重来。
先判断限流是暂时拥堵还是工具已经不适合继续用
限流本身只说明调用频率或配额触发了限制，不能直接证明工具失效。可区分的信号有几类：如果返回的是明确的频率限制提示，且间隔一段时间后单次调用能成功，通常属于暂时拥堵；如果连续多次返回鉴权失败、接口不存在或结果结构变化，则更像工具或对接方式已经变化。此时继续加大重试没有意义，应转为保留已有结果并评估退出。
一个实际动作是先做单次探测：暂停批量脚本，只调用一个已知链接，记录返回状态和结果字段。若单次成功，说明可以降速续跑；若单次仍失败，下一步就不是调参，而是检查工具是否还适合当前用途。这一步的价值在于把“限流”与“工具不可用”分开，避免在错误方向上消耗时间。
保留已有结果的最低要求：原始返回、进度标记、可追溯标识
限流后最怕的是脚本重跑时覆盖旧文件，或者只留下处理后的汇总而丢掉原始返回。保护已有结果至少要做到三点：原始响应单独存放，不覆盖；每个链接记录完成状态，而不是只记录总数；保留查询时使用的标识，例如链接本身、查询参数和调用时间。这样即使后续换工具，也能知道哪些结果来自哪次调用。
- 原始层：把每次链接查询的原始返回按批次写入独立文件，追加而不覆盖。
- 进度层：维护一个已完成清单，记录成功、失败、未调用三种状态。
- 标识层：为每条记录保留链接和参数，便于换工具后比对口径是否一致。
假设一个脚本要处理一千条链接，跑到三百条时被限流。如果原始返回和进度清单都在，续跑时只需从第三百零一条开始；如果只有一份汇总表，就无法判断缺失的是哪七百条，只能全部重来。这里的数字仅用于说明比较方法，不代表任何工具的实际配额。
续跑、改写还是退出：三种取舍各自的适用前提
限流后的选择不是只有“继续重试”。可以按前提区分：当单次探测成功、限流只是频率问题时，适合降速续跑；当工具仍可用但结果字段或口径发生变化时，适合改写脚本而不是直接沿用旧解析逻辑；当工具已经无法稳定返回、或这批旧内容的查询价值本身在下降时，适合保留结果并退出，不再追求跑完。
退出的判断依据不是“这次被限流了”，而是继续投入是否还能改变决策。如果这些链接查询结果只用于一次已经完成的迁移核对，那么保留已查到的部分、标注未覆盖范围，往往比继续消耗调用更合理。反之，如果结果要进入长期监测，就需要先解决稳定调用方式，再谈续跑。
重试要有边界，否则会破坏已有结果
无边界重试会把限流变成数据损坏的入口：同一批次被反复写入、进度标记被覆盖、失败与成功混在一起。给重试设边界，至少包括最大次数、间隔递增和失败落盘。达到边界后停止，把未完成清单保留下来，交由人工判断是降速续跑还是退出。
- 遇到限流先停止当前批次，不继续并发调用。
- 把失败条目写入待处理清单，保留原始错误信息。
- 等待后只探测单条，成功再按更低频率续跑。
- 达到重试上限仍失败，则冻结进度，转为评估工具或退出。
这样做的结果是：下一步动作由探测结果决定，而不是由脚本自动硬扛。已有结果始终可读、可续、可核对。
旧系统退出时，哪些链接查询结果值得留下
当旧内容、旧系统或旧合作关系需要退出时，不必保留全部查询结果。值得留下的是仍会影响后续判断的部分：曾经用于决策的关键链接、出现异常或冲突的记录、以及能说明查询口径的少量样本。其余结果可以只保留汇总和覆盖范围说明。
具体动作是先按用途给结果分层，再决定保留粒度。若某批链接查询只服务于已经结束的核对，保留汇总和未覆盖清单即可；若结果还要用于迁移后的抽查，则应保留原始返回和标识。完成分层后，退出动作才有明确边界，不会把仍有价值的部分一起删掉。
