排名查询：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /fd9a85e3c884.html
📄
排名查询：脚本调用工具遇到限流时怎样保护已有结果
先把结论说清楚：限流发生时，最该保护的不是“把这一轮查完”，而是已经拿到的结果和已经确认过的查询位次。正确顺序是先停止继续请求，把当前结果落盘并标记完整度，再用断点续跑的方式补齐缺口。否则重试风暴会把已有数据冲乱，甚至让你分不清哪些位次是真实查到、哪些是失败后被默认值填充的。
为什么限流时最危险的动作是立刻重试
限流本质上是服务端在告诉你当前请求节奏已经超出可接受范围。此时如果脚本立刻进入 while 重试或并发补发，会形成两个后果：一是新请求继续被拒，二是已有结果可能被后续失败响应覆盖。尤其是当你的结果写入逻辑是“每轮先清空再写入”时，一次限流就可能把之前几小时查到的位次全部清掉。
更隐蔽的问题是状态混淆。假设你查询 500 个词，前 300 个成功，后 200 个被限流。如果脚本对失败项写入空值或 0，最终文件看起来是一次完整查询，但其中 200 条其实是失败占位。之后你拿这份数据做决策，就会把“没查到”误当成“没有排名”。
判断依据：看结果里是否出现大量连续空值、位次突然全部靠后、或同一批词在短时间内数值完全一致。这些更可能是限流后的失败填充，而不是真实排名变化。
先给已有结果做一次冻结
限流出现后，第一步不是修脚本，而是冻结当前结果。具体动作：把内存中的结果和已写入文件各复制一份，文件名带上时间戳和状态标记，例如 rank_raw_20240601_1030_partial.json。不要在原文件上继续追加，也不要用新结果覆盖旧文件。
冻结之后，检查三件事：已成功查询的词有多少、失败或被限流的词有多少、每个词的最后一次成功查询时间是什么。这个检查决定了下一步是“继续补查”还是“重新设计查询节奏”。如果失败比例很低，补查即可；如果失败比例很高，说明当前调用方式本身需要调整。
动作结果如何影响下一步：如果冻结文件里成功项和失败项能清楚区分，你就可以只针对失败项发起补查，避免重复请求已成功的词。如果两者混在一起无法区分，就必须先重建查询清单，再决定是否重跑。
把查询任务改成可断点续跑的结构
保护已有结果的根本办法，是让每次查询都独立可记录。可以按下面的结构组织：
- 为每个查询词生成唯一标识，例如关键词加目标地区加设备类型。
- 每条结果写入时附带状态字段：
success、rate_limited、failed。 - 成功项只写一次，后续补查只处理非成功项。
- 每完成一批就落盘一次，而不是等全部跑完再写。
这样即使中途被限流，已有成功结果也不会丢。补查时读取状态为 rate_limited 或 failed 的条目即可，不需要重新查询全部关键词。
假设你查询 200 个词，第一批 80 个成功，第二批触发限流。采用断点续跑时，补查只针对剩余 120 个词，而且可以放慢节奏分批执行。若采用全量重跑，则 80 个已成功词也会被再次请求，既浪费额度，也更容易再次触发限流。
限流后的请求节奏要按证据调整，而不是凭感觉
限流解除后，不要立刻恢复到原来的并发数。先做小批量试探：取 5 到 10 个失败词，用低于原节奏的方式请求，观察是否再次被限流。如果这批成功，再逐步增加批量；如果仍然被限流，说明限制条件不只是频率，可能还涉及并发数、单账号调用量或时间窗口。
需要区分几种合理解释：
- 短时间请求过多，属于频率限制。
- 同一账号并发过高，属于并发限制。
- 当日累计调用量触顶，属于配额限制。
- 目标服务临时不稳定，返回了类似限流的错误。
这几种情况的处理方式不同。频率限制可以拉长间隔，并发限制需要降低同时请求数，配额限制则只能等待窗口重置或更换合规的调用方式。把限流一律当成“重试就好”，通常会让问题反复出现。
补查完成后要验证结果，而不是直接使用
补查结束并不等于数据可用。需要做一次完整性检查：成功项数量是否等于原计划查询数量，是否存在重复关键词，是否有状态仍为失败的条目。如果补查后仍有失败项，应在结果文件中保留明确标记，不要用空值代替。
最后一步是把冻结文件和补查结果合并成一份带状态说明的最终文件。合并后，先抽查几个已知位次的关键词，确认补查结果与冻结结果没有冲突。如果同一关键词在两次查询中位次不同，应记录两次查询时间，而不是简单取其中一个值。
限流场景下，保护已有结果的核心不是追求一次跑完，而是让每次成功查询都可追溯、可续接、可验证。做到这一点，限流只会让查询变慢，不会让已有结果失效。
