死链处理方法：抓取日志与应用日志时间不一致时怎样对齐事件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /82d53632045a.html
📄
死链处理方法：抓取日志与应用日志时间不一致时怎样对齐事件
先给结论：不要试图把两份日志“调成同一个时间”，而要建立一条只依赖相对顺序的事件链。抓取日志记录的是爬虫何时请求了某个 URL，应用日志记录的是服务器何时处理了这次请求；两者时间不一致通常来自时钟偏差、时区设置、日志写入延迟或中间层缓存。缺少完整数据或权限时，最小动作是选取同一 URL 在短时间窗口内的两条记录，按顺序配对，而不是按绝对时间相等配对。
先判断不一致属于哪一类，再决定对齐方式
时间不一致有两种性质完全不同的情况，处理选择也不同。
- 固定偏移：两份日志的差值在同一时间段内大致恒定，例如总是相差几分钟或整小时。这通常指向时区配置或系统时钟未同步。此时可以给其中一份日志整体加上偏移量后再比对。
- 浮动偏移：差值忽大忽小，甚至出现应用日志早于抓取日志的情况。这通常指向日志缓冲、异步写入、队列积压或时钟漂移。此时整体平移会制造新的错误配对，应当放弃绝对时间对齐。
判断依据不是看单条记录，而是取同一时间段内至少十条可对应的请求，计算每对的差值，观察差值是否稳定。差值稳定才考虑平移；差值不稳定就转入顺序对齐。
条件一：能拿到请求标识时，用标识对齐而不是用时间
如果抓取请求带有可传递的标识，例如自定义请求头、查询参数中的追踪值，或应用侧记录了 User-Agent 与路径的组合，就优先用这些字段配对。动作是：在抓取日志中筛出目标 URL 的请求时间，在应用日志中按相同标识筛出对应处理记录，两者配对后只保留相对先后关系。
这样做的影响是：你得到的是“爬虫先请求、应用后处理”或相反的顺序，而不是两个绝对时间戳。下一步判断死链时，只需要确认应用是否对该 URL 返回了表示不存在的状态、是否触发了跳转、是否根本没有匹配到处理记录。时间差本身不再参与结论。
条件二：拿不到标识时，用短窗口加路径唯一性做近似配对
缺少请求标识或应用日志粒度较粗时，退而求其次：选取一个在窗口内只出现一次的 URL 路径，把窗口收窄到分钟级，再按顺序配对。动作是先排除高频重复路径，只保留低频路径作为样本，然后检查同一路径在抓取日志和应用日志中的出现次数是否一致。
这里必须说明不能推出的结论：次数一致不代表处理成功，次数不一致也不能单独证明存在死链。应用日志缺失可能只是因为该请求被缓存层直接响应、被限流丢弃，或日志采样没有覆盖到。抓取日志出现请求也不代表该 URL 已被索引。要确认死链状态，仍需回到该 URL 当前实际返回的响应，而不是只靠两份日志的时间关系。
一个假设例子：偏移稳定与偏移浮动会导向不同动作
假设某站抓取日志显示 10:00 请求了 /old-page，应用日志显示 10:07 处理了同一路径。若抽查另外九条记录，差值都在七分钟左右，可以按固定偏移处理，把应用日志整体前移后再比对，结论相对可靠。若这十条记录的差值在几秒到十几分钟之间跳动，就不能平移；此时应改用请求标识或路径唯一性配对，并接受部分记录无法对应。
这个例子的数字只用于说明比较方法，不代表任何真实站点的实际偏差。
对齐之后，死链处理动作和例外
对齐事件的目的是判断某个 URL 是否真的返回了不存在状态，以及这个状态是长期存在还是瞬时出现。确认长期返回不存在后，常规动作是：对仍有价值的 URL 设置指向最相关现页的跳转，对无价值的 URL 返回明确的不存在状态并停止在站内继续链接它。对瞬时错误，先观察是否重复出现，不急于改配置。
例外情况需要单独记录：如果应用日志显示返回了不存在状态，但抓取日志中该 URL 仍被频繁请求，可能只是外链或站点地图仍指向它，并不说明处理无效。如果两份日志都对某 URL 没有记录，也不能据此认定它正常，可能只是该时间段没有抓取发生。任何单一计数归零，都需要先排除采样、缓存和权限范围这些解释，再下结论。
