上周三凌晨两点，批量我盯着屏幕上第47个返回“连接超时”的检测网址，意识到手动点击这件事该结束了。网站那是打开一个客户发来的Excel表格，里面塞了200多条推广链接，批量要求我确认哪些还能正常访问。检测前10个我还耐着性子等浏览器转圈，网站到第20个的打开时候，手指已经条件反射地在Ctrl+C和Ctrl+V之间来回切换，批量眼睛开始发花。检测这不是网站技术活，这是打开体力活。批量检测网站能不能打开，批量本质上就是检测把这种体力活交给脚本去跑。

最直接的网站办法是用Python的requests库。写个循环，把URL列表读进来，逐个发HEAD请求，看返回的状态码。200、301、302都算活着，404、502、ConnectionError就标记为异常。代码不到二十行：

import requests urls = open('sites.txt').read().splitlines() for url in urls: try: r = requests.head(url, timeout=5, allow_redirects=True) print(url, r.status_code) except requests.RequestException as e: print(url, 'FAIL', type(e).__name__) 

跑起来很快，200个链接大概两分钟出结果。但这里有个坑——很多网站对HEAD请求不友好，要么返回405，要么直接拒绝。换成GET请求更稳妥，只是速度慢一些，因为要下载页面内容。我的习惯是设stream=True，拿到响应头就断开，不实际下载body。这样既绕过了HEAD的限制，又不会浪费带宽。

状态码只能告诉你“服务器有响应”，不代表“页面内容正常”。我遇到过返回200但页面是“该域名已过期”的停放页，也见过301跳转到钓鱼站的情况。所以光看状态码不够，还得加一层内容校验。简单做法是检查页面标题或特定关键词，比如if '无法访问' in r.text[:2000]。更严谨的话，用BeautifulSoup解析title标签，跟预期值做比对。这一步会拖慢速度，但准确率从70%拉到95%以上。

并发是绕不开的话题。单线程跑500个链接，每个超时5秒，最坏情况要40多分钟。用concurrent.futures的ThreadPoolExecutor开20个线程，时间直接压到两三分钟。不过线程不是越多越好——我试过开100个，结果本地网络先扛不住，大量请求报Too many open files。20到30个线程是比较舒服的区间，具体看目标网站的承受能力。别把人家服务器打挂了，这跟DDoS的边界很模糊。

实际用的时候，我会把结果分成三列：正常、异常、可疑。异常是连接失败或5xx，可疑是3xx跳转或内容不匹配。输出成CSV，用Excel打开，标黄可疑项，标红异常项。客户拿到手一目了然。有次一个客户坚持说某个链接“肯定没问题”，我把他拉进终端，当场跑了一遍，返回ConnectionRefusedError。他沉默了几秒，说“那台服务器上周迁移了”。

工具选择上，不想写代码的话，curl加xargs也能凑合：cat urls.txt | xargs -I{ } -P 20 curl -o /dev/null -s -w "%{ http_code} { }\n" { }。一行命令，20个并发，输出状态码和URL。Windows用户可以用PowerShell的ForEach-Object -Parallel，或者干脆装个WSL。再懒一点，Chrome插件“Check My Links”能扫当前页面的所有链接，但批量导入外部列表就不行了。

我现在的流程固定下来了：先用脚本跑一遍并发检测，拿到原始状态码；再对可疑项做二次内容校验；最后人工抽查几个异常结果，确认不是误报。整套下来，500个链接大约五分钟出报告。比手动点击快了不知道多少倍，而且不会因为凌晨两点犯困而漏掉第138个。