死链检查：错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /de582b9c0031.html
📄
死链检查：错误只在特定时段出现时怎样捕捉短暂证据
先给结论：如果错误只在特定时段出现，优先选择“把检查动作绑定到那个时段并留下可复查记录”，而不是事后翻日志猜原因。两种做法都成立，但条件不同。选择依据是：你能否稳定复现时段、能否在错误发生时留下原始响应，以及错误是否与固定触发条件有关。假设错误集中在每天 02:00–03:00，某产品页返回 <404> 或超时，而白天正常。此时白天跑一遍死链检查几乎必然漏掉它，因为检查没有落在错误窗口内。实际动作是：把定时检查调到该时段，并让每次请求保存状态码、最终 URL、响应耗时和重定向链。结果会直接决定下一步——若记录里出现同一最终 URL 的 <404>，就转向该 URL 的发布与回滚记录；若记录里只有超时，则先查该时段的服务器负载和上游依赖，而不是改链接。
选择一：定时窗口内检查，适合能稳定复现的时段
当错误时段可预测时，最省成本的做法是让死链检查在窗口内运行，并保留每次请求的原始状态。判断条件：错误每天或每周在相近时间点出现，且持续几分钟以上。实施动作：把检查任务安排在错误窗口开始前几分钟启动，覆盖窗口结束后几分钟，记录每个链接的状态码、最终 URL、耗时和重定向次数。这样做的代价是检查频率受限于窗口长度，窗口外的变化不会被覆盖。结果如何影响下一步：若同一 URL 在窗口内稳定返回 <404>，说明问题与该时段的某个动作有关，下一步查该时段的发布、缓存刷新或定时任务；若状态码在窗口内也时有时无，说明单次检查不够，需要在该窗口内提高采样次数，而不是扩大全天检查范围。
选择二：持续采样加告警，适合时段不稳定但影响大的情况
如果错误时段并不固定，或每次只持续几十秒，定时窗口很容易错过。此时应选择持续采样：对关键链接保持固定间隔请求，并在连续失败达到设定次数时触发告警。判断条件：错误影响核心页面，且你无法预测下一次出现时间。实施动作：对少量高价值 URL 做高频采样，同时保存失败前后的响应片段。代价是请求量上升，可能给源站带来额外压力，因此采样对象要控制在关键集合内。结果如何影响下一步：若告警在多个时段都出现，说明不是单一时段问题，应回到常规死链检查流程；若只在某个时段集中出现，再收窄到该时段做定点检查。
捕捉短暂证据时，哪些记录才真正有用
短暂错误最难的不是发现，而是留下能复查的证据。只记“某链接失败”通常不够，因为无法区分是链接失效、重定向异常还是服务端短暂不可用。至少应保留以下字段：
- 请求发生的时间戳，精确到分钟，便于与发布、缓存和定时任务对照。
- 原始状态码，以及最终 URL。若发生重定向，记录完整跳转链。
- 响应耗时。超时和 <404> 的处理方向不同，耗时能帮助区分。
- 同一 URL 在错误窗口前后的对照结果。只有前后都正常、窗口内失败，才更能说明与时段有关。
这些记录的作用是缩小下一步范围：状态码稳定为 <404> 时，优先查该 URL 是否被错误下线；状态码为 <5xx> 或超时时，优先查该时段的资源与依赖，而不是直接判定为死链。
一个假设例子：如何用对照结果决定下一步
假设某分类页在每天凌晨批量任务运行后返回 <404>，白天恢复。做法 A 是白天跑一次死链检查，结果正常，无法解释夜间问题。做法 B 是在凌晨任务前后各检查一次，并保存两次的最终 URL。若任务前正常、任务后变为 <404>，且最终 URL 指向一个临时路径，下一步应查该批量任务是否改写了链接或清理了缓存；若两次都正常，只是中间偶发超时，则不应把它当作死链处理，而应继续观察该时段的负载。这个例子的数字只用于说明比较方法，不代表任何真实项目结果。
例外与适用条件
定时窗口内检查并不适合所有情况。如果错误时段本身不稳定，窗口检查会给出“正常”的假象，此时持续采样更合适。反过来，持续采样也不适合全站铺开，因为请求量和告警噪声会掩盖真正问题。另一个例外是：如果错误只出现在登录态或特定地区，匿名检查可能完全看不到，需要先确认检查请求是否覆盖了相同条件。还要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些与短暂错误无关，不能用来解释时段性失败。最后，任何单次归零或单次失败都不能单独证明处理正确，应结合前后对照和多个时间点的记录再决定是否修改链接或回退。
