站长工具综合查询：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7a3b5c0fa4f5.html
📄
站长工具综合查询：脚本调用工具遇到限流时怎样保护已有结果
先保住已经拿到的数据，再决定改脚本还是换路径。限流发生时，最危险的动作是让脚本继续重试并把同一批结果重新写一遍——旧结果被覆盖、去重键错乱、进度标记失效，往往比限流本身损失更大。正确顺序是：立即停止写入、把当前结果落成不可变快照、记录限流信号，然后才考虑降速续跑、改写请求方式或退出该接口。
先冻结结果：把“已有结果”变成不可变快照
脚本被限流的瞬间，内存里可能还有一批未落盘的数据，磁盘上则有一份正在被追加或覆盖的结果文件。此时不要先改代码，先做三件事：
- 停止后续请求，避免限流窗口继续累积。
- 把当前结果文件复制成带时间戳的快照，例如
result_20240101_1200.jsonl，后续续跑只读快照、写新文件。 - 记录本次运行的状态：已完成的查询键、最后一条成功记录的键、失败或中断的位置。
这样做的直接结果是：无论后面选择降速重试还是换接口，原始结果都不会被新数据污染，去重和断点续跑都有据可依。如果结果文件是覆盖写而非追加写，快照就是唯一能证明“限流前拿到了什么”的证据。
区分限流的三种成因，再决定保留还是改写
限流不一定等于“请求太多”。在决定降速、改写还是退出之前，先用可核对的证据区分成因，因为不同成因对应完全不同的处理动作。
成因一：单位时间请求数超限
证据是：错误码或响应头明确指向频率，且降低请求速率后同一接口恢复正常。这种情况下保留结果最划算——快照有效，只需在续跑时加入间隔和退避。
成因二：单次请求负载或参数被判定异常
证据是：同一速率下，某些查询键稳定失败，另一些稳定成功；失败与查询键或参数长度相关，而非与时间相关。此时降速无效，需要改写请求粒度，把一次大批量查询拆成多次小批量，并且只对失败键重跑。
成因三：账号、IP 或会话层面的额度耗尽
证据是：同一凭证下所有接口同时失败，更换凭证或等待更长时间后恢复。此时继续重试只会加深封禁，应把已有结果封存，评估是否等到额度重置，或改用其他数据来源。
三种成因的区分方法是：固定其他变量，只改变一个因素（速率、参数、凭证），观察失败是否随之变化。如果换了速率仍然失败、换了参数就成功，那么限流只是表象，真正的问题是请求结构。
降速续跑：适用前提与具体动作
降速续跑适合“结果已基本完整、只差少量键”的场景。前提是：快照可读、已完成键可枚举、接口在低速率下确实恢复。动作是：
- 从快照中读出已完成键集合。
- 只对未完成键发起请求，写入新文件而非追加到快照。
- 每次失败后按固定倍数拉长等待，等待期间不发起任何请求。
- 续跑结束后，用已完成键集合做一次合并去重，再和快照比对总数。
这个动作的结果是：即使续跑中途再次限流，快照和续跑文件都各自完整，合并逻辑可重复执行。如果续跑文件出现重复键，说明去重键选错了，应回到快照检查键的构成，而不是继续重试。
改写请求：什么时候值得放弃原路径
当限流由请求结构引发时，降速只会把同样的失败拖得更久。改写请求的适用前提是：已经确认失败与参数、批量大小或查询方式相关，且改写后能通过小样本验证。可考虑的方向包括：
- 把一次大批量查询拆成按维度分批的小查询，降低单次负载。
- 把实时查询改为对已缓存结果的二次加工，减少对外部接口的依赖。
- 把同步串行改为带节制的队列，让请求速率可控、可暂停、可恢复。
改写前先用少量键做对照：同一批键分别用旧方式和改写方式请求，比较成功率和返回结构。只有改写方式在相同速率下成功率明显更高，才值得把已有结果迁移到新流程；否则应保留原结果，等待限流窗口过去。
退出的判断：什么证据出现时不该再续跑
退出不是失败，而是避免把有限额度消耗在无法成功的请求上。出现以下任一证据时，应停止续跑并封存结果：
- 更换凭证、降低速率、改写参数后，同一接口仍然持续失败，且失败与请求内容无关。
- 接口返回的错误信息指向权限、配额或服务状态，而非请求频率。
- 续跑多次后，新增成功键数量为零或接近零，而失败键集合没有缩小。
注意，请求量归零或抓取量归零本身不能证明“处理正确”。它也可能来自目标页面结构变化、接口返回格式改变或本地解析逻辑出错。要区分这些解释，可以手动取一个已知曾成功的键重跑一次：如果手动请求也失败，问题在接口侧；如果手动成功而脚本失败，问题在脚本侧。
假设一个场景：脚本已采集 800 个键，限流后降速续跑只新增 5 个键，失败键仍有 300 个，且更换凭证后失败键不变。此时更合理的判断是请求结构或目标本身有问题，而不是速率问题。下一步应停止续跑，保留 805 个键的快照，转而核对失败键的输入格式和目标可达性，而不是继续消耗额度。
把保护动作固化成流程
限流是脚本调用外部工具时的常态，真正决定结果价值的是限流发生那一刻的写入策略。把“先快照、再判断成因、后决定续跑或退出”固定成脚本的默认行为，比任何单次调参都更可靠。每次运行结束时，至少保留一份带时间戳的结果文件和一份运行状态记录，这样下一次无论选择保留、改写还是退出，都有可核对的起点。
