网站安全扫描工具，脚本调用限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d3d302f47b0.html
📄
网站安全扫描工具，脚本调用限流时怎样保护已有结果
限流发生时，最该保护的不是“继续扫完”，而是已经拿到的结果与已确认的判定。做法是先冻结结果写入、把已完成部分落成可复核的快照，再决定是降速续跑还是换执行窗口；如果限流来自目标侧而非工具侧，继续重试往往只会让更多请求被拒，此时应停止续扫，先验证已得结果是否足以支撑当前决策。
先分清限流来自哪一侧，决定了你要不要继续跑
脚本调用扫描工具时，限流可能出现在两个位置：一是工具自身的接口配额或并发上限，二是被扫描目标对请求频率的限制。两者表现相似，但处理方向相反。
- 工具侧限流：同一账号下其他任务也在消耗配额，或调用频率超过工具约定。特征是换目标、换时间后仍可能复现，且错误信息通常与配额、并发、调用频率相关。
- 目标侧限流：只有针对某个域名或IP的请求被拒，其他目标正常。特征是同一脚本扫别的站点没问题，只有这一个目标持续返回拒绝或超时。
判断方法：把脚本指向一个已知可正常响应的对照目标，观察是否同样被拒。若对照目标正常，问题大概率在目标侧，继续重试没有意义；若对照目标也被拒，问题在工具侧，可考虑调整调用节奏或等待配额恢复。
限流瞬间要做的三件事：冻结、落盘、标记
很多脚本在收到限流响应后仍会继续消费已返回的数据，甚至把不完整的响应写进结果集，导致后续无法区分“扫过且干净”和“没扫到”。限流一旦触发，第一步是停止新的请求，而不是加大重试。
- 冻结结果写入：暂停把新响应合并进主结果文件，避免半截数据污染已有判定。
- 落盘快照：把当前已完成的结果单独写成一个带时间标记的文件，并记录已扫描的目标范围、已完成的检查项、未开始或中断的检查项。
- 标记状态：给每个目标标注“已完成”“部分完成”“未开始”，部分完成的要写清断在哪一步。
这个动作的直接结果是：你得到一份可独立复核的结果集，而不是一个状态不明的半成品。下一步无论续跑还是换工具，都以这份快照为基线。
降速续跑还是换窗口：用两个条件来选
假设一个情境：你有一批内部资产需要周期性扫描，脚本调用扫描工具时，前若干目标正常返回，之后开始收到限流响应。此时有两个选择成立的不同条件。
条件一，选择降速续跑：限流来自工具侧，且配额会随时间恢复；或者目标侧限制较宽松，只是瞬时并发过高。此时把并发调低、在请求之间加入间隔、对失败项做有限次数的退避重试，通常能继续推进。注意退避要有上限，超过上限的项应标记为未完成，而不是无限重试。
条件二，选择换执行窗口或分批：限流来自目标侧且限制较严，或工具侧配额在当次窗口内不会恢复。此时继续在同一窗口内重试只会重复被拒，应把剩余目标拆到不同时间段，或先完成高优先级目标，其余留到下一个周期。
判断依据不是“重试几次能成功”，而是：剩余目标是否必须在本次窗口内完成。如果本次结果只是用于周期性巡检，分批完全可以接受；如果本次结果要支撑一次即将发生的变更决策，则需要评估已有快照是否已覆盖关键目标。
用已有结果做决策前，先确认覆盖边界
限流导致的中断会让结果集出现覆盖缺口，而缺口位置往往比缺口本身更危险。续跑前先回答：当前快照覆盖了哪些目标、哪些检查项，未覆盖部分是否包含你真正关心的资产。
一个可操作的做法是给结果集加两列：coverage（已完成/部分完成/未开始）和source（本次快照/上次快照）。如果关键目标全部为“已完成”，且检查项完整，那么这份结果可以支撑当前决策；如果关键目标处于“部分完成”，则应先补齐该目标，再考虑其余目标。
这里要避免一个常见误判：把“本次没有发现新问题”当成“目标安全”。限流中断后，未扫描的部分本来就不会产生发现，请求量下降或结果为空都不能单独证明处理正确，它们同样可能只是中断造成的。
续跑后如何验证结果没有被污染
续跑完成后，不要直接把新结果合并进旧快照。先做一次对照：对同一批已完成目标，比较续跑前后的判定是否一致。若出现同一目标前后结论不同，需要先查清原因——是目标状态确实变化，还是两次调用使用了不同的检查项或判定口径。
确认一致后，再按目标合并，并保留合并记录。这样即使后续再遇到限流，你仍然能回到上一个可信基线，而不是面对一份无法解释来源的结果集。
最后，把限流当作流程的一部分来设计：脚本层面预留快照写入和状态标记，执行层面预留分批窗口，决策层面明确“覆盖到什么程度可以下结论”。具体工具的配额、并发上限和重试策略需要以该工具当前实际说明为准，不同工具差异较大。
