写博客工具：脚本调用遇到限流时保留、改写还是退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7d61574035e1.html
📄
写博客工具：脚本调用遇到限流时保留、改写还是退出
先给结论：限流本身不是删除已有结果的信号。真正决定保留、改写还是退出的，是这些结果是否已经落盘、能否区分“完整批次”与“半截批次”，以及后续调用是否必须依赖同一接口。只要原始响应已保存，优先保留并标记；只有确认结果缺字段、顺序错乱或对应关系断裂时，才改写或退出。
先判断限流发生在哪一层
同样提示“请求过多”，落在不同层，处理方式完全不同。第一层是脚本自身节流：本地队列把并发压到某个数量以下，通常只影响新任务，不影响已返回内容。第二层是接口侧限流：返回状态码或错误信息，已有结果仍在。第三层是工具链上的中间服务限流：例如把写博客工具的输出再送进另一个处理环节，这时断点可能在中间，而不是原工具。
可区分的证据包括：错误是否带明确的状态码或重试提示；同一批任务里是否只有部分条目失败；把并发降到单线程后是否仍然失败。若单线程仍失败，通常更接近接口侧限制；若单线程恢复正常，问题更可能在本地调度。这个判断直接影响下一步：前者要保护已有结果并等待，后者只需调整脚本节奏。
保留的适用条件：结果已落盘且可定位
满足下面几个条件时，保留是默认动作：每条结果带有唯一标识，能对应回输入；原始响应已写入文件或数据库，而不是只存在内存；失败条目与成功条目能分开列出。
实际动作可以这样做：把每次调用写成一条追加记录，字段至少包含输入标识、返回内容、时间、状态。遇到限流时先停止新请求，把已写入的记录冻结，再单独生成一份失败清单。这样做的结果是，后续重试只需补失败清单，不必重跑全量。重试时也不会覆盖已经正确的结果。
需要注意，请求量归零并不等于处理正确。它也可能来自队列提前退出、脚本异常中断或上游返回被静默丢弃。要确认保留是否完整，应核对输入总数、成功条数、失败条数三者是否对得上，而不是只看有没有报错。
改写的适用条件：结果存在但不能直接使用
有些情况下结果确实拿到了，却无法直接进入下一步。典型情形是：返回内容被截断，字段缺失，或者顺序与输入不再一一对应。这时改写比直接退出更划算，前提是原始响应仍然保留，改写只针对副本。
假设一批任务共一百条，限流后成功返回七十条，其中十条缺少结尾字段。此时合理做法是保留全部七十条原始记录，只把缺字段的十条挑出来，缩小请求范围后重试。这里的一百、七十、十只是说明比较方法的假设数字，不代表任何工具的实际额度。判断改写是否值得，可以看两个条件：缺失部分是否能用更小请求补回；补回成本是否低于重新生成全部结果。
如果截断发生在写入之前，且原始响应没有留存，改写就失去了依据。这种情况下继续修补容易把不完整内容当成完整内容使用，风险高于重新执行。
退出的适用条件：依赖关系已断或结果不可信
退出不是失败情绪，而是一个明确判断：当前批次的结果已经无法与输入对应，或者继续调用会破坏已有数据。常见触发条件包括：脚本在写入过程中被中断，导致同一标识出现多条互相冲突的记录；限流后返回的内容格式与之前明显不同，无法合并；后续步骤强依赖完整批次，缺一条就不能继续。
退出时仍要保护已有结果。动作是停止写入、给当前批次打上未完成标记，并把已落盘内容移到独立位置，而不是直接删除。这样做的结果是，后续可以选择在干净状态下重跑，也可以人工检查哪些记录仍可用。若不做隔离，重跑时新旧记录混在一起，反而更难判断哪份可信。
把选择变成可执行的分支
可以把判断压缩成三个问题。第一，原始响应是否已经保存？没有保存，优先停止并保留现场，不要继续追加请求。第二，失败条目能否单独识别？能识别，就保留成功部分，只重试失败部分。第三，后续步骤是否要求整批一致？要求一致且当前批次已不完整，就隔离本批并重新开始；不要求一致，就带着失败清单继续推进。
这套分支的价值在于，它把“限流”从一个笼统的中断，拆成保留、改写、退出三种可验证的选择。每次选择之后，都应该留下一条可复查的记录：哪些结果被保留，哪些被改写，哪些被隔离。下一步是否重试、重试多少、是否需要人工介入，都从这份记录出发，而不是从错误提示本身出发。
