pr 查询：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5ab9636d50d8.html
📄
pr 查询：脚本调用工具遇到限流时怎样保护已有结果
遇到限流时，先保住已经拿到的部分，再决定是继续等待、改写调用方式还是退出。多数工具在触发限流后仍允许你把已返回的记录落盘；真正危险的是让脚本在重试中覆盖或丢弃这些结果。下面按“保留、改写、退出”三条路径说明各自适用的前提，以及一个不依赖完整权限也能执行的最小动作。
先判断限流发生在哪一层，再决定保什么
限流可能来自三个位置：脚本自身设定的并发上限、工具服务端对调用频率的限制、以及网络出口被目标站点拒绝。三者表现相似，但处理方式不同。如果响应里带有明确的重试等待提示，说明是服务端在告诉你节奏；如果连接直接超时或被重置，更可能是出口或中间层的问题。
无论哪一种，第一步都是把当前批次的结果写入独立文件，而不是留在内存里等全部跑完。可以按“每成功一条就追加一行”的方式落盘，文件名带上批次标识和时间戳。这样即使进程被中断，下次启动也能从最后一条记录继续，而不是从头再来。
能做什么：把已返回的记录序列化到本地，记录每条对应的查询参数。这不需要额外权限，也不依赖工具是否提供断点续传功能。
不能推出什么：已落盘条数等于总条数，或者限流解除后一定能补齐剩余部分。落盘只证明这些结果曾经返回过，不代表剩余查询会成功。
保留：什么条件下值得先停下来等
如果限流是短时的、且有明确的重试时间窗口，保留现有结果并暂停是最省成本的选择。适用前提是：你已经拿到的数据本身有独立价值，等待期间不需要继续消耗调用额度，且业务上没有必须在几分钟内出结果的硬约束。
具体动作可以是：脚本捕获限流信号后，不再发起新请求，把当前进度和已获取记录写入一个状态文件，然后退出并返回一个可识别的退出码。下一步由人来决定何时重启，或由定时任务在等待窗口之后重新拉起。这个动作的结果是：你保住了已有结果，同时避免了在限流期内反复重试导致的更长时间封禁。
需要注意的是，等待策略只在限流原因明确时成立。如果响应中没有重试提示，只是持续失败，那么“等一等就好”只是一种假设，不能当作事实。
改写：降低单次请求压力，换取继续执行
当限流频繁出现但并非完全封禁时，改写调用方式比直接退出更合适。常见做法包括：把并发数降到 1、在请求之间加入固定间隔、把一次大批量查询拆成多个小批次、以及把必须实时获取的部分与可以延迟获取的部分分开处理。
改写的前提是你能接受更长的总耗时，并且拆分后的每个小批次仍然能对应到原来的查询目标。例如，假设原本一次提交 100 个查询条件，被限流后改为每次 10 个、间隔几秒，那么总时间会明显拉长，但每条结果的归属关系不变。这里的数字只是说明比较方法，实际间隔需要根据工具返回的提示或你自己的观察来确定。
动作与影响：把并发和批量调小之后，如果错误率下降，说明限流与请求压力相关；如果错误率不变，则更可能是权限、参数或目标侧的问题，继续调低并发不会改善，应该转向排查其他原因。
退出：什么时候不该继续消耗调用
如果出现以下情况，退出比继续重试更合理：限流伴随明确的封禁提示；已获取结果已经满足当前任务的最低需要；继续调用会挤占其他更重要的查询额度；或者你无法确认剩余查询是否仍在授权范围内。
退出的动作不是简单关掉脚本，而是把已有结果整理成可交付的状态：标明哪些查询已完成、哪些未完成、未完成的原因是限流还是其他错误。这样下一次执行时，接手的人或脚本能直接从未完成部分开始，而不必重新判断。
退出时不能推出的结论是：未完成的查询永远拿不到，或者限流意味着账号有问题。限流只是当前调用节奏与对方接受节奏不匹配，和账号状态、数据正确性没有必然关系。
缺少权限或数据时仍可执行的最小动作
如果你没有完整的数据访问权限，也看不到工具内部的调用日志，仍然可以做一件事：在脚本里加一层结果缓存，把每次成功返回的原始响应按查询条件存下来。这个动作不要求额外权限，也不要求你理解限流的具体规则。
缓存建立之后，后续无论选择等待、改写还是退出，你都不会丢失已经付出的调用成本。更重要的是，当限流解除后重新执行时，脚本可以先检查缓存中是否已有对应结果，只对缺失部分发起请求。这一步的影响是：把“是否被限流”从一个阻断性问题，变成一个只影响剩余工作量的进度问题。
需要核对的是：缓存键必须能唯一对应查询条件，否则不同条件的结果可能互相覆盖。这一点在查询条件包含空格、大小写或编码差异时尤其容易出错，建议在写入前先做一次规范化处理。
