死链检测需综合处理重定向、反爬、假200等场景：用requests.head()配合allow_redirects=true与max_redirects=5，捕获toomanyredirects；区分404/410/503/500为死链，403/401为受限；对200响应校验content-type及正文内容。
死链检测不能只靠 requests.get() 加个超时就完事——真实网页常有重定向、反爬响应、HTTP/HTTPS 混用、301/302 循环、甚至返回 200 却是“页面不存在”模板，直接判断状态码会漏判或误报。
用 requests.head() 避免下载正文，但得手动处理重定向
HEAD 请求比 GET 更轻量，适合批量探测，但它默认不跟随重定向（allow_redirects=False），而很多死链实际卡在跳转链末端。必须显式开启并限制跳转次数，否则可能陷入循环或超时：
- 设置
allow_redirects=True，同时用max_redirects=5控制跳转深度（requests 默认是 30，太高风险） - 捕获
requests.TooManyRedirects异常，这类链接大概率已失效或配置错误 - 对
404、410、503、500明确标记为死链；403和401视为“访问受限”，单独归类，不等同于死链
识别“假 200”：检查响应内容或 Content-Type
有些网站对无效路径仍返回 200，但响应体含 “Not Found”、“404 Page” 或 Content-Type: text/html 却无正文内容。这时要加一层校验：
- 若状态码是 200，且
response.headers.get("Content-Type", "").startswith("text/html")，再用len(response.text) 或正则匹配常见错误提示（如 <code>r"404|not found|page does not exist"，忽略大小写） - 避免全文本解析：只取前 2KB（
response.content[:2048]）做检查，防止大页面拖慢速度 - 不要依赖
BeautifulSoup做全量解析——死链检测是 IO 密集型任务，HTML 解析是 CPU 密集型，混在一起会严重拖慢吞吐
并发控制与请求头伪装，绕过基础反爬
批量扫链接时，不加限制的并发容易被封 IP 或触发 429；不带请求头则大概率被当成爬虫直接拒收：
- 用
concurrent.futures.ThreadPoolExecutor控制线程数（建议 5–10，取决于目标服务器承受力），别用asyncio+aiohttp——多数死链场景下 DNS 解析和 TLS 握手才是瓶颈，多线程更稳 - 必设
User-Agent，例如{"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"}；部分站点还检查Accept，补上"Accept": "text/html,application/xhtml+xml" - 每域名加
time.sleep(0.3)级别的节流（非全局），比统一限速更贴近真实浏览器行为，也降低被识别概率
输出结果要区分“不可达”“拒绝访问”“真死链”三类状态
单纯标“失败”没意义。一个链接可能是 DNS 失败（requests.exceptions.ConnectionError）、SSL 验证失败（requests.exceptions.SSLError）、超时（requests.exceptions.Timeout），或是服务端明确返回 404。这三类问题修复路径完全不同：
- “不可达”（DNS/连接/SSL 类）需检查网络或 URL 格式（比如漏了
https://） - “拒绝访问”（401/403/429）要确认权限或加 Cookie / Token
- “真死链”（404/410）才该通知编辑删链接
- 输出 CSV 时，列名建议为：
url,status_code,final_url,error_type,checked_at，其中error_type填connection/timeout/http_404等可筛选字符串
真正难的不是发请求，而是定义“什么是死链”——它取决于你的业务场景：是面向搜索引擎优化？还是内部 Wiki 维护？前者要严格识别 410 和 noindex，后者可能连 301 跳转都算“链有效”。工具可以跑起来，但阈值和分类逻辑得你亲手调。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
