站点管理工具：脚本限流时保留、改写还是退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c547f30157eb.html
📄
站点管理工具：脚本限流时保留、改写还是退出
当站点管理工具里的脚本因限流中断，已有结果是否可靠，取决于限流发生在取数、处理还是写回阶段。先别清空任务，把已完成部分冻结成可核对快照，再决定保留、改写还是退出，通常比直接重跑更稳。
先判断限流卡在哪一段，结果价值完全不同
限流不是单一事件。脚本通常分三段：向站点管理工具请求数据、在本地或中间层处理结果、把结论写回报告或任务系统。若中断发生在请求段，已落地的原始响应仍有核对价值；若发生在处理段，半成品可能混入不完整字段；若发生在写回段，最危险的是部分结果已覆盖旧结论。
可区分的原因至少有三类：一是请求频率触发了对端限制；二是同一凭据被多个脚本并发占用；三是脚本自身重试逻辑过密，把临时错误放大成持续限流。三者的证据不同：第一类通常表现为整批请求同时失败，第二类表现为部分角色成功、部分失败，第三类则会在日志里看到短时间密集重试。请求量归零或抓取量骤降不能单独证明限流已解除，也可能是目标站点变更、网络中断或脚本提前退出。
实际动作：立即停止自动重试，把当前输出另存为只读快照，记录时间点、已完成条目数和失败位置。这个动作的结果决定下一步——如果快照能覆盖关键字段，就有保留基础；如果关键字段大量缺失，改写或退出更合适。
保留：适合结果仍可核对、失败边界清晰时
保留不等于继续跑。适用前提是：已完成部分有稳定主键，失败条目能明确列出，且下游不要求全量一致。此时把快照标记为“部分完成”，让执行人员只处理已确认部分，未完成部分进入待办，而不是混在同一份结论里。
做法上，先冻结字段口径，再补一张失败清单。失败清单至少包含三类信息：被限流的请求标识、最后一次成功返回的时间、该条目对应的事实来源。这样多个角色对同一事实有不同理解时，分歧能落到具体条目上核对，而不是争论整份报告可不可信。
假设例子：某次脚本计划核对两百个页面的标题与状态码，限流后只完成一百二十个。若这一百二十个的主键、标题、状态码都齐全，可先交付这部分；剩余八十个单独列为未核对。若下游要求“全站一致”，保留就不成立，应转向改写。
改写：适合限流可绕开、但结果结构需要调整时
改写的核心不是换工具，而是换调用方式。常见前提是：限流来自请求节奏而非权限，且已有结果的结构仍可用。可把一次大批量请求拆成按目录或按时间片的小批，加入退避间隔，并把中间结果先落盘再汇总。这样即使再次被限流，损失也只落在当前小批。
改写时要保留旧快照作为对照，不要直接覆盖。新一批结果与旧快照的差异应逐条记录，尤其是同一对象出现不同结论时，先核对口径再决定采信哪一方。若多个角色对“完成”定义不同，改写前应把定义写成可核对字段，例如“已取到状态码”与“已确认状态码正确”是两件事。
实际动作：把脚本的批量参数调小，增加失败后等待再试的间隔，并将每次小批输出单独存放。结果如何影响下一步：若小批能稳定完成，说明限流是节奏问题，可继续改写；若小批仍立即失败，说明限制更可能在凭据或权限层，应退出自动调用，转人工核对。
退出：适合写回已污染、或权限层受限时
退出不是放弃，而是停止用脚本继续影响已有结果。适用前提包括：写回阶段已覆盖旧数据且无法区分新旧；同一凭据被限制且短期无法更换；或脚本逻辑本身依赖已被限流的接口，继续跑只会制造更多半成品。
退出时要做的是隔离而非删除。把当前输出移出主流程，保留原始日志和失败清单，标注“未验证”。然后由人工或另一条不依赖该接口的路径补齐关键条目。若必须重跑，也应从干净快照开始，而不是在污染结果上叠加。
判断依据：如果失败条目与成功条目共用同一写回通道，且无法按主键回滚，退出优先；如果写回可按条目回滚，保留或改写仍有空间。
把分歧转成可核对的项目
多个角色对结果是否可用有不同理解时，不要用“再跑一次”当结论。把分歧拆成三个可核对项：哪些条目已确认、哪些条目仅取到原始响应、哪些条目完全未处理。每一项都对应一个负责人和一个验收动作。这样限流带来的不确定性被限制在具体条目里，而不是扩散成整份报告的信任问题。
最后提醒：不同站点管理工具对失败重试、并发控制和结果落盘的支持程度不同，具体按钮、额度和日志字段需要以你正在使用的版本为准。先冻结快照，再根据失败边界选择保留、改写或退出，才是限流后保护已有结果的稳妥顺序。
