挂马扫描软件：脚本调用工具遇到限流时怎样保护已有结果
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /f64c09c2c5aa.html
📄
挂马扫描软件：脚本调用工具遇到限流时怎样保护已有结果
限流发生时，最该保护的不是“继续跑完”，而是已经拿到且尚未落盘的结果。把扫描拆成“发现—落盘—复核”三段，限流只影响发现段，落盘和复核照常推进，这样即使调用被中断，已有结果仍可审计、可续跑。下面用一个假设情境把决策过程串起来。
假设情境：单样本正常，批量后开始被限流
假设你用挂马扫描软件对一台服务器做脚本化巡检：先取一批可疑文件路径，再逐个调用扫描接口判断是否含恶意脚本。手工测三个文件时一切正常；扩到几百个文件后，接口开始返回“请求过多”或超时。这时要区分两件事：限流是调用侧触发的，还是目标侧本来就慢。前者表现为固定时间窗内失败率上升、间隔后恢复；后者表现为个别大文件持续超时、与请求频率无关。判断错方向，后续动作会完全不同。
先落盘再判断，别让结果只活在内存里
脚本常见错误是把所有结果攒在内存，最后统一写文件。一旦限流中断进程，前面跑完的部分全部丢失。改成逐条追加写盘：每完成一个文件的扫描，立即把路径、判定结果、时间戳、工具返回的原始状态写入一个中间文件（如 JSON Lines）。这个动作的直接影响是——限流后你仍有一份可复核的清单，而不是从零重跑。
- 中间文件记录“已判定”和“待判定”两类状态，续跑时只处理待判定项。
- 原始返回状态要保留，不要只存最终结论，否则复核时无法判断是超时还是明确判定。
- 写入失败本身也要记录，避免把“写不进去”误当成“没扫到”。
限流下的三种取舍，条件不同选法不同
保护已有结果之后，才轮到决定要不要继续。三种做法各有成立条件：
- 降速续跑：适用于限流是频率触发、且总样本量可控。在请求间加固定间隔，牺牲总时长换完整覆盖。若间隔后仍失败，说明不是单纯频率问题。
- 分批暂停：适用于目标侧本身不稳定。把剩余样本切成小批，每批结束后落盘并暂停，下一批在确认上一批结果完整后再开始。
- 先复核已有结果：适用于限流原因不明、且已判定样本中已出现可疑项。先人工或二次扫描确认这些项，再决定是否继续扩大范围。
注意：请求量下降、失败率归零，都不能单独证明“限流已解除”。也可能是样本恰好变小、缓存命中、或脚本提前退出了。要结合时间窗和样本特征一起看。
一个动作：把“判定”和“处置”解耦
限流期间不要顺手做删除、隔离等写操作。把脚本职责限制在“读取与判定”，处置动作留给复核后的人工或独立流程。原因是：限流时工具返回可能不完整，基于不完整结果做写操作，风险远大于晚一点处理。这个动作的结果是——扫描脚本可随时中断、随时续跑，而不会留下半完成的处置状态。下一步的复核清单，就直接来自那份已落盘的中间文件。
续跑前先做一致性检查
从中间文件恢复时，先核对三件事：已判定数量与预期是否吻合、是否存在同一路径多条记录、时间戳是否连续。若同一路径出现互相矛盾的判定，说明限流期间返回不可靠，应以复核后的结论覆盖，而不是简单取最新一条。具体到某个品牌工具的返回字段含义、当前版本是否支持断点续传、有无内置重试，需要以该工具的现行文档为准，不同版本可能不同，不能照搬。
把发现段与落盘、复核分开，限流就只是拖慢进度，不会毁掉已有成果；反之，任何一次中断都可能让整轮扫描白跑。
