应设置 timeout=(3,7) 控制连接与读取超时，显式指定 allow_redirects=False 避免跳转失控；提取链接需覆盖多标签并用 urljoin 处理相对路径；报告聚焦坏链率折线图、TOP10 域名条形图及状态码堆叠图；并发限速、随机延迟、遵守 robots.txt 并规范 UA。
用 requests 发起请求时如何正确处理超时和重定向？
坏链检测最常卡在请求挂起或跳转失控上。默认 requests.get() 没有超时，遇到无响应站点会卡死；而重定向过多（比如循环跳转）又容易触发 TooManyRedirects 异常，但默认不抛出——得显式控制。
- 必须设置
timeout=(3, 7)：第一个数字是连接超时（秒），第二个是读取超时，避免单个请求拖垮整个扫描 - 显式传入
allow_redirects=False，先检查原始 URL 状态码；若需跟进跳转，再用requests.head(url, allow_redirects=True)单独探查最终目标 - 对
403、401这类“拒绝访问”状态码，不要直接判为坏链——有些资源需 User-Agent 或 Referer 才能访问，可加简单 headers 后重试一次
解析 HTML 提取链接时怎么避开常见陷阱？
用 BeautifulSoup 解析时，a[href] 看似简单，但实际会漏掉大量链接来源，比如 link[rel="stylesheet"]、script[src]、img[src]，甚至内联 JavaScript 中的动态拼接 URL。
- 优先用
soup.find_all(['a', 'link', 'script', 'img', 'iframe'], href=True)+src=True组合提取，覆盖主流资源标签 - 绝对 URL 直接保留；相对 URL 必须用
urllib.parse.urljoin(base_url, relative_path)转换，否则跨目录时路径会错乱 - 过滤掉
javascript:、mailto:、tel:等非 HTTP 协议链接，避免后续请求失败 - 去重不能只靠字符串相等——要 normalize：统一 scheme 小写、去掉末尾斜杠、解码 URL 编码（用
urllib.parse.unquote()）
生成可视化报告时哪些图表真正有用？
坏链分析不是炫技，核心就三个问题：哪里坏了？为什么坏？影响多大？柱状图和饼图容易误导，比如按域名统计坏链数，但没考虑每个域名的总链接量，看不出真实失效率。
- 必做「坏链率」折线图：横轴是采集时间点（或页面层级深度），纵轴是
bad_count / total_count，能看出爬取过程是否越来越差 - 用水平条形图展示 TOP10 坏链域名，并标注其总链接数和坏链数，比单纯排序更直观
- 状态码分布用堆叠条形图（而非饼图）：区分
4xx和5xx，再细分404、410、502等，便于定位是内容删除还是服务故障 - 输出 HTML 报告时，用
plotly.express生成交互图表，嵌入本地file://路径即可打开，不依赖服务器
大规模扫描时如何避免被封 IP 或压垮目标站？
并发一高，要么自己被反爬拦截，要么对方服务器返回 503 或直接断连。这不是性能问题，是协议尊重问题。
立即学习“Python免费学习笔记（深入）”；
- 严格限制并发数：用
concurrent.futures.ThreadPoolExecutor(max_workers=3)，别碰asyncio——多数网站不支持 HTTP/2，异步反而增加连接开销 - 每请求间加随机延迟：
time.sleep(random.uniform(0.5, 2.0))，避免规律性请求暴露脚本特征 - 主动识别并遵守
robots.txt：用urllib.robotparser.RobotFileParser().read()检查can_fetch(user_agent, url)，尤其对/admin/、/api/类路径 - 记录
User-Agent并留联系邮箱（如"MySiteChecker/1.0 (admin@mydomain.com)"），很多运维看到合规 UA 会放行
坏链检测真正的难点不在代码，而在平衡：既要足够鲁棒地覆盖各种 URL 变体和响应异常，又不能把探测行为变成攻击。每次加新规则前，先拿已知坏链样本跑一遍，看是否误杀或漏判——比写一百行逻辑都管用。
