关键字批量查询：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /33d700e63bd1.html
📄
关键字批量查询：脚本调用工具遇到限流时怎样保护已有结果
限流发生时，最该保住的不是“继续跑完”，而是已经拿到的结果和已经消耗掉的额度记录。能续跑就落盘断点，不能续跑就立即封存快照；两种选择的分界，是任务是否具备可重复的请求标识和稳定的分片顺序。
先判断能不能续跑，而不是先重试
限流通常表现为请求被拒、返回变慢或响应里出现配额提示。它不等于任务失败，也不等于数据源已经变更。真正决定下一步的是：你的脚本能否证明“这一批请求已经处理过”。
- 可续跑的条件：每个分片有稳定编号或键值，已处理项能写入本地文件或数据库，且重跑同一分片不会产生重复写入。
- 不可续跑的条件：请求靠临时游标推进，游标只存在内存里；或者结果直接写入远端表，没有本地中间层。
如果满足可续跑条件，动作是停止发起新请求，把当前进度、最后成功项和失败项分别落盘，然后按退避间隔重试。结果会决定下一步：若重试后仍被拒，就切换到封存模式，不再消耗额度试探。
封存快照时要保留哪些字段
封存不是把结果导出就完事。缺少上下文的快照，过几天连自己都无法判断它覆盖了哪一段查询范围。
- 请求参数原文：查询词、分片编号、时间范围、地区或语言等筛选条件。
- 返回状态：成功、限流、超时、空结果，四类分开记录，不要把空结果当失败。
- 抓取时间与脚本版本：用于判断两次快照之间数据口径是否变化。
- 未处理清单：明确哪些分片尚未发起请求，而不是笼统写“未完成”。
这样做的结果是，后续无论是换工具、换账号还是等额度恢复，都能从清单继续，而不是从头再查一遍。
两种条件下的不同选择
条件一：你有完整权限，只是被临时限流。此时优先保断点，等待窗口恢复后从失败分片继续。因为权限完整意味着数据源本身可达，缺的只是节奏。
条件二：你缺少部分权限或数据源本身不完整。此时不要反复重试被拒的分片，而应把已成功部分标记为“部分覆盖”，并在交付说明里写清未覆盖范围。继续重试只会消耗剩余额度，且无法把缺失权限变成可用。
一个假设例子：某次批量查询共 200 个分片，成功 120 个后开始限流。若脚本记录了分片编号，恢复后可只跑第 121 至 200 个；若没有记录，只能全部重跑，已消耗的 120 次请求相当于白费。这个比较只说明断点记录的价值，不代表任何真实平台的额度规则。
不能从限流现象推出的结论
请求被拒、抓取量下降或某项统计归零，都不能单独证明你的处理方式正确，也不能证明数据源已经失效。合理解释至少包括：短时配额用尽、并发过高、参数触发风控、网络抖动，或对方服务临时调整。要区分这些原因，需要看失败是否集中在同一分片、同一时间窗或同一类参数上。
因此，限流期间最稳妥的动作是降速并记录，而不是换 IP、换账号或修改参数硬闯。这些做法可能让已有结果失去可复现性，反而增加后续核对成本。
最小可执行动作与例外
即使缺少完整权限，也能先做一件事：把已返回的结果按分片写入本地文件，并生成一份未处理清单。这个动作不需要额外权限，却能保住已有成果。例外是，如果本地文件包含敏感字段，应先确认存储位置和访问范围，再决定是否落盘。
恢复调用前，先用一个分片做小流量验证，确认返回结构与之前一致，再放开其余分片。若验证结果与快照口径不同，应新建快照而不是覆盖旧文件，以便对比差异来源。
