降权查询：脚本被限流后如何保住已取回的结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d4089a11cdb9.html
📄
降权查询：脚本被限流后如何保住已取回的结果
先给结论：脚本触发限流时，最该做的不是继续重试，而是立刻停止请求，把已经拿到的原始响应原样落盘，并记录每条结果对应的查询参数、时间和状态码。这样即使后续补查失败，你手里仍有一份可复核、可继续加工的半成品，而不是一堆只在内存里存在、一崩就全丢的数据。
先区分限流发生在哪一层，再决定保什么
同样是“查不动了”，原因不同，保住已有结果的方式也不同。常见的有三类：一是请求频率超过对方允许的节奏，返回明确的限流状态；二是鉴权或配额耗尽，后续请求直接被拒；三是网络或脚本自身超时，看起来像限流，其实对方并没有拒绝你。
判断依据可以看响应本身：如果返回体里带着限流相关的提示字段、重试等待时间或配额余量，基本可以确认是服务端在限流；如果只是连接超时、DNS 失败或进程被系统杀掉，那更可能是本地问题。这个区分很重要，因为前者需要退避等待，后者需要先修本地环境，盲目等待只会浪费时间。
假设一个场景：你写脚本批量查询一批页面，跑到第 300 条时开始连续返回限流状态。此时正确动作是让脚本在第一次遇到限流时就进入“保护模式”，而不是硬跑到全部失败。保护模式要做的第一件事，就是把内存里已经成功的记录写进文件。
把内存里的结果转成可恢复的落盘结构
很多人丢数据，不是因为限流，而是因为结果只存在列表变量里，脚本一退出就没了。要保住成果，落盘结构至少要让每条记录能回答四个问题：查的是哪个对象、用的什么参数、什么时候查的、返回的原始内容是什么。
一个务实的做法是用一行一条的 JSON 记录，每条包含查询键、请求时间、状态和原始响应。不要在这一步就急着清洗、去重或转成报表格式，因为原始响应一旦被改写，后面出现争议时你就无法回溯。清洗是下一步的事，先保证“不丢”。
具体动作：在脚本里加一个“成功即追加写入”的逻辑，每拿到一条有效结果就立即追加到文件，而不是等全部跑完再统一保存。这个动作的结果是，脚本哪怕在第 301 条被限流中断，前 300 条也已经安全落盘，你下一步要处理的只是“如何补齐剩余部分”，而不是“如何重跑全部”。
限流后不要立刻重试，先做三件事
遇到限流就马上重试，往往会让等待时间越来越长，甚至把临时限制变成更长时间的封禁。更稳的顺序是：
- 停止发送新请求，让脚本进入等待或退出，避免继续消耗配额。
- 确认已落盘文件的完整性，比如统计成功条数、检查最后一条是否写完整，防止出现半行 JSON。
- 记录本次中断的位置，也就是下一个待查的键是什么，方便恢复时从断点继续。
这三件事做完，你才有资格谈“要不要继续”。如果落盘文件本身不完整，继续补查只会让数据更难对齐。
恢复查询时，用断点续跑代替全量重跑
保住已有结果之后，恢复策略决定了你还要付出多少成本。最省的做法是断点续跑：读取已落盘文件里的查询键集合，跳过它们，只查剩下的。这样既避免了重复请求触发再次限流，也不会覆盖已经拿到的结果。
同时要把请求节奏调慢。限流通常和单位时间内的请求数有关，把并发降下来、在请求之间加入等待，往往比换 IP 或换账号更可持续。需要说明的是，具体等待多久、并发降到多少，取决于对方公布的限制规则；如果没有公开规则，只能通过观察响应中的提示来试探，并且要接受“可能仍会被限流”这个前提。
假设你原本每秒发 5 个请求，被限流后改成每 2 秒发 1 个，剩余 200 条大约需要几分钟跑完。这只是说明节奏与耗时的关系，不是推荐值，实际节奏必须按对方规则调整。
哪些部分值得保留，哪些可以放弃
限流中断往往也是一个清理时机。已经落盘的结果里，可能混着无效返回、重复记录和过时数据。判断保留与否，可以看三点：这条结果是否对应你真正要查的对象；它的时间是否还在你可接受的范围内；它的原始响应是否完整、可复核。
对于旧内容、旧系统或旧合作关系退出场景，尤其要区分“历史记录”和“当前有效结果”。历史记录的价值在于留档和对比，不一定要参与后续决策；当前有效结果才需要补齐。把这两类分开存放，可以让你在补查时只针对后者，减少请求量，也就降低了再次被限流的概率。
最后提醒一点：限流只是现象，不能单独用来证明你的查询方式正确或错误。请求量下降、抓取变慢，也可能是对方服务调整、网络波动或你本地环境变化造成的。把响应状态、时间和参数一起记录下来，才能在事后判断到底发生了什么，并决定下一步是继续补查、调整节奏，还是改用其他合规的数据获取方式。
