链接互换工具，脚本调用遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c8b2ef85260b.html
📄
链接互换工具，脚本调用遇到限流时怎样保护已有结果
先给有条件的结论：如果脚本调用链接互换工具时遇到限流，而你已经拿到一部分返回结果，最稳妥的动作是先停止继续请求，把已到手的数据原样落盘并记录每条结果对应的请求参数与时间，再决定是否重试。这样做的价值是保住“已确认”的部分，避免后续重试把旧结果覆盖或混入不完整记录。但这条结论有一个失效条件：如果限流响应本身携带了明确的重试等待信息，且你的脚本能区分“本次请求失败”与“上次结果需要作废”，那么立即按等待时间重试也可以，前提是重试不会覆盖本地已有记录。缺少完整数据或权限时，你仍能执行的最小动作是保存原始响应和请求上下文，但由此不能推出“剩余数据一定拿得到”，也不能推出“限流消失后结果口径不变”。
先落盘再重试，顺序错了会丢什么
限流发生时，脚本往往处于循环中途。此时内存里可能只有最后一批结果，磁盘上还没有写入。若直接进入重试逻辑，常见两类损失：一是重试成功后新结果覆盖旧文件，而新结果可能因为限流只返回了部分字段；二是重试一直失败，进程退出后内存数据全部丢失。
可执行的动作是：在捕获到限流信号的那一步，先把当前批次写入一个带时间戳的临时文件，再决定是否重试。判断是否写入成功的依据不是脚本是否抛异常，而是文件能否被独立读取并包含预期的记录条数。这一步的结果会直接影响下一步：只有确认落盘完整，才适合继续请求；否则应先修复写入逻辑，而不是加大重试次数。
区分“请求失败”和“结果作废”
限流通常意味着请求未被处理，但不等于之前已成功的结果失效。保护已有结果的关键，是让脚本能区分三种状态：已成功且已落盘、已成功但未落盘、未成功。只有第二种需要优先抢救，第三种可以延后。
- 已落盘的成功结果：不要因为后续限流而删除或重写。
- 未落盘的成功结果：优先写入，不发起新请求。
- 未成功的请求：记录参数，等限流缓解后再补。
如果脚本无法区分这三种状态，那么“保护已有结果”就无从谈起。此时的最小动作是给每条记录加上请求标识和状态字段，而不是先优化请求频率。
一个假设例子：两批数据与一次限流
假设脚本要调用链接互换工具查询 100 条记录，每批 20 条。第 3 批返回限流，此时前两批已成功。若脚本在第 3 批失败后直接从头重跑，那么第 1、2 批可能被重复请求，既浪费配额，也可能因返回顺序变化导致本地记录错位。若脚本先保存前两批，再只对第 3 批之后重试，则已确认的 40 条不会被动摇。这个例子中的数字只用于说明比较方法，不代表任何真实工具的配额或返回规模。
从这个假设可以推出的结论是：分批落盘比整批落盘更能缩小限流造成的损失。不能推出的是：分批一定不会被限流，或者重试一定成功。
哪些信号说明该停，哪些只说明该等
遇到限流时，先看返回内容里有没有可区分的信号。如果响应明确表示“请求过多，稍后重试”，且没有返回业务数据，那么这属于该等的情况。如果响应里混有部分业务数据，同时附带限流提示，那么这属于该停的情况：先保存这部分数据，再判断它是否完整。
一个反例是：限流响应看起来像成功响应，字段结构相同，只是数值为空。若脚本只检查状态码而不检查字段完整性，就可能把空结果当成有效结果写入，覆盖掉之前已落盘的正确记录。此时保护已有结果的唯一办法是保留旧文件，不直接覆盖。
下一步动作：先做可逆的，再做不可逆的
限流缓解后，不要立刻全量重跑。先做可逆动作：复制一份已有结果，在副本上补缺失部分。确认补齐后的记录数与预期一致，再替换原文件。若缺少完整数据或权限，无法核对总数，那么至少保留原始响应和请求日志，并明确标注“未完成核对”。
这样做的结果是：即使后续重试仍然失败，你手里仍有一份可追溯的中间状态，而不是从零开始。下一步是否继续请求，取决于这份中间状态是否足以支撑你当前的判断；如果不足以支撑，就先补日志和字段说明，而不是继续消耗请求次数。
