百度推广查询，脚本限流后怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ccf39e6c3296.html
📄
百度推广查询，脚本限流后怎样保护已有结果
先给结论：限流发生时，最该保护的往往不是“继续跑完”，而是把已经拿到的百度推广查询结果变成可续跑、可核对、可交接的本地资产。具体做法是让脚本每处理完一个查询单元就落一次盘，把成功结果、失败原因和未执行项分开保存，再用断点文件记录进度；这样限流结束后，你只需补跑未完成部分，不必从头再来，也不会把半截数据当成完整结论。
先判断你手里的是“样本成立”还是“规模后失效”
很多脚本在十几个查询对象上跑得很顺，一旦扩展到几百个就触发限流，原因通常不是脚本写错了，而是请求节奏、并发数和单次返回体量一起变了。此时不要急着调大超时或重试次数，先分清三种信号：
- 请求被拒：返回明确的限流或频繁提示，说明节奏问题，重试间隔应拉长。
- 请求成功但内容异常：返回空页、验证页或结构变化，说明触发了风控或页面形态变了，继续跑只会污染数据。
- 本地写入失败：网络正常但文件没落盘，说明是脚本自身的存储逻辑问题，和限流无关。
这三种情况的处理动作不同。把限流当成唯一原因，会让真正的问题被掩盖。一个可用的判断动作是：暂停脚本，手动取一个刚失败的查询对象，看返回的是拒绝信号还是内容异常。如果是内容异常，下一步应该改解析逻辑或核对查询对象，而不是单纯放慢速度。
把一次查询拆成可落盘的单元
保护已有结果的核心，是让每个查询对象的处理结果都有独立归属。假设你手上有 200 个需要做百度推广查询的词或页面，不要等全部跑完再统一写文件，而是每完成一个就追加写入。可以按下面的结构组织本地文件：
done.jsonl：每行一条成功结果，包含查询对象、抓取时间、原始返回摘要。failed.jsonl：每行一条失败记录，包含查询对象、失败类型、重试次数。pending.txt：尚未执行的查询对象清单，每次启动时读取。
动作上，脚本启动时先读 pending.txt，每处理完一个对象就从清单中移除并写入对应结果文件。这样即使中途被限流打断，下次运行也能从剩余清单继续。结果的直接影响是：你不再需要判断“上次跑到哪了”，清单本身就是进度。
限流触发后的暂停与恢复策略
限流一旦出现，继续高频重试通常会让情况更糟。更稳妥的顺序是：先停止新请求，把当前内存中的结果强制刷盘，再记录触发限流的时间点和已完成的最后一个查询对象。恢复时可以按以下条件决定节奏：
- 如果失败集中在短时间内连续出现，说明并发过高，应降低并发数并增加请求间隔。
- 如果失败分散且间隔较长，可能是单次返回体量或查询对象本身触发了限制，应缩小单次查询范围。
- 如果重试后仍然失败，应把该对象移入失败清单，先跑其余对象，避免一个卡点拖住整体进度。
这里要说明适用条件：降低并发和拉长间隔能缓解节奏型限流，但对内容异常型失败帮助有限。若手动核对后发现返回的是验证页或结构变化，应先调整解析规则或查询方式，再恢复批量执行，否则补跑多少次都拿不到可用结果。
用一个小例子验证续跑是否真的可靠
假设你只有 5 个查询对象，想验证这套机制是否成立。可以先跑前 2 个，然后手动中断脚本，检查 done.jsonl 是否有 2 条记录、pending.txt 是否只剩 3 个对象。再次启动后，脚本应只处理剩余 3 个，而不是重复前 2 个。这个假设例子说明的是比较方法：用可观察的文件状态判断续跑逻辑，而不是凭感觉认为“应该没问题”。
如果验证时发现重复处理，说明去重逻辑依赖了内存而不是文件，需要把已完成对象也写入清单比对。这个动作的结果会直接影响下一步：只有续跑可靠，限流后的补跑才有意义；否则你保护的只是看起来完整的半份数据。
给结果加上可核对的边界说明
限流期间拿到的数据，时间跨度可能被拉长，不同查询对象的抓取时点不一致。交付或分析前，应在结果旁标注每个对象的抓取时间、是否经过重试、以及失败清单中未完成的部分。这样做的原因是：限流导致的暂停会让部分结果偏旧，如果不说明，读者容易把不同时点的数据当成同一批次比较。
最后一步是把成功、失败和未执行三份清单一起保留，而不是只留最终合并表。合并表看起来整齐，却丢掉了失败原因和覆盖范围；一旦后续要判断某个查询对象是否真的查过，三份清单才是可追溯的依据。
