淘宝热词查询：脚本被限流时怎样保住已抓结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /72fa3fae09dd.html
📄
淘宝热词查询：脚本被限流时怎样保住已抓结果
先给结论：限流发生后，不要重启脚本从头再抓。第一步是冻结当前结果文件，把已成功的查询键和失败键分开，再决定是补抓、降速续抓还是换接口。因为限流通常只影响请求通道，不影响你已经拿到的数据，盲目重跑反而会用重复请求换回一批可能被截断的结果。
先冻结现场：把结果文件变成可恢复的台账
假设你手头有一个脚本，按关键词列表逐条调用某个热词查询工具，输出一个 JSON 或 CSV。运行到一半开始返回限流错误，此时文件里通常混着三种记录：完整成功、字段缺失、以及根本没写进去的失败项。处理顺序应该是先备份，再解析，而不是先改脚本。
具体动作：把当前输出文件复制一份并加上时间标记，然后写一个只读的解析脚本，逐条判断每条记录是否包含你依赖的核心字段。判断结果决定下一步——如果成功记录占比高且字段完整，优先做断点续抓；如果大量记录字段缺失，说明限流可能发生在响应中途，此时补抓比续抓更安全。
这一步的结果会直接影响后面的策略：台账越干净，续抓的边界越明确；台账越混乱，越应该缩小单次请求量，重新验证一小批。
区分限流的两种形态，决定是等待还是降速
限流不只有一种表现，处理方式也不同。
- 硬限流：请求直接被拒绝，返回明确的频率或配额错误。此时等待一段时间通常能恢复，但恢复后的可用额度未知。
- 软限流：请求仍返回数据，但字段变少、结果被截断或返回空集。这种更危险，因为它会污染你的结果文件，让你误以为某个词没有热度。
判断依据是看响应本身的完整性，而不是看请求是否报错。如果同一关键词在限流前后返回的结构不一致，就应按软限流处理：把这些记录标记为可疑，不纳入最终统计。
一个可用的短例子：假设你有 200 个词，脚本在第 80 个词开始变慢。此时先取第 70 到 80 个词各重跑一次，对比字段是否一致。若一致，说明只是速度问题，可以降速续抓；若不一致，说明结果不可信，需要重新定义抓取批次。这个对比数字只是说明方法，不代表任何真实工具的配额。
把续抓拆成小批次，并给每批留下可核对的锚点
限流环境下，最忌讳一次性提交整个关键词列表。更稳妥的做法是把剩余关键词切成小批次，每批只处理固定数量，并在每批结束后记录三个信息：本批关键词、成功条数、失败原因。这样即使下一批又被限流，你也能清楚知道损失范围。
锚点指的是每批里保留一两个已经确认成功的词，用来验证接口是否仍然返回相同结构。如果锚点词的结果发生变化，说明当前通道不可信，应暂停而不是继续消耗请求。
这一步的实际影响是：你不再需要判断“脚本还能不能跑”，而是判断“这一小批结果能不能用”。决策粒度变小，恢复成本也随之下降。
保护已有结果的三个具体动作
- 写入前先校验：在脚本里增加字段完整性检查，缺字段的记录不写入主结果文件，而是进入待核查区。这样主文件始终只保留可信数据。
- 记录请求指纹：为每个关键词保存查询时间、参数和返回结构摘要。限流后可以据此判断是参数问题还是通道问题。
- 设定停止条件：连续若干次失败或锚点校验不通过时自动停止，而不是无限重试。停止后由人工决定是换时间段、换查询方式，还是接受当前结果。
这三个动作的共同结果是：限流不再等于数据作废。你手里始终有一份边界清晰、可继续使用的数据集。
什么时候应该放弃补抓，改用已有结果
不是所有限流都值得继续对抗。如果剩余关键词占比很小，而核心词已经抓完，继续补抓的边际价值可能低于重新整理已有结果。反过来，如果缺失的恰好是决策依赖的关键词，那就必须补，但应优先用更保守的方式补，比如降低频率、缩小批次或改在低峰时段执行。
判断标准可以落到一个问题上：缺失的这部分词，是否会改变你接下来的选品、投放或内容判断？会，就补；不会，就把已有结果整理成可用版本，并明确标注覆盖范围。这比反复重跑更接近可执行的处理方案。
