如何从数据库中排查并移除项目中的失效URL？

一、批量URL有效性检测：减少误杀是核心 #

1. 多轮重试+状态码细分，排除临时故障 #

• 先用HEAD请求替代GET，省带宽还不容易触发反爬。要是返回4xx/5xx，先标「待复核」，别直接判死刑。
• 对首次异常的URL，分三次重试：间隔1小时、6小时、24小时各来一次。只有三次全挂，才标记成「疑似无效」——毕竟很多站点只是临时宕机或者网络抽风。
• 状态码要细着来：
  • 直接算无效：404（资源彻底删了）、410（明确移除）、400（URL本身格式就错了）
  • 先放一放：500、502这类服务器错误，还有超时、连不上的情况，都归到待复核
  • 自动更新：遇到3xx重定向，直接抓新URL替换旧的，原URL标「已迁移」就行

2. 控好流量，别被目标站拉黑 #

• 按域名限速：同一个域名下，每秒最多发1-2个请求，别扎堆薅人服务器。
• 加随机延迟：在限速基础上，每次请求间隔随机加个几百毫秒，模拟真人访问的节奏。
• 分散IP：要是有多余服务器，就分多个节点发请求，单个IP的请求量降下来，不容易被反爬拦截。

二、数据库清理：稳字当头，别乱删 #

1. 先标记再隔离，留好后路 #

• 给数据库加个status字段，选项设成「正常/待复核/疑似无效/已迁移」，检测结果先写这个字段，别直接删数据。
• 建个临时表，把「疑似无效」的记录挪过去，原表不动——万一后面发现误判，还能导回来。

2. 人工复核兜底，尤其是高价值数据 #

• 抽个5%-10%的疑似无效URL人工查一遍，验证检测逻辑准不准。特别是VIP用户的收藏链接，优先复核，别把人家重要的东西删了。
• 对那些存疑的（比如返回404但可能是需要登录才能看的页面），单独拎出来手动访问确认。

3. 观察期过后再删，还得留备份 #

• 等个7-14天，确认那些临时宕机的站点都恢复了，再把临时表里的疑似无效记录批量删掉。
• 删除前一定要导出全量备份，存到离线硬盘里——真出问题了还能救回来。

三、长期维护：别等堆成山再处理 #

• 增量检测：新添的URL24小时内完成首次检测；老URL每3-6个月全量复检一次。
• 用户反馈入口：整个「报告无效链接」的按钮，用户标记的优先处理，还能省自己的检测成本。
• 域名黑名单：对那些反复检测全无效的域名，以后再有人加这个域名的链接，直接标待复核，不用浪费资源检测。

内容的提问来源于stack exchange，提问作者Vikas R