如何在Python中编写具有自我修复能力的自动化网络爬虫脚本？-Python教程-PHP中文网

直接加重试逻辑反而让爬虫更脆弱，根本原因在于未区分异常类型：timeout与connectionerror需分别处理，429应触发代理轮换而非简单休眠，dns失败需切换解析器，503应依据retry-after头动态休眠，且应通过httpadapter+retry将重试下沉至urllib3层，避免手动循环遗漏连接池复用等细节。

如何在python中编写具有自我修复能力的自动化网络爬虫脚本？

为什么直接加重试逻辑反而让爬虫更脆弱

很多开发者一上来就给 requests.get() 套三层 try/except + time.sleep()，结果发现：超时没捕获、重定向循环、状态码 429 被当成功、代理失效后全量失败。根本问题不在“重不重试”，而在“重试前是否做了有效诊断”。requests.exceptions.Timeout 和 requests.exceptions.ConnectionError 必须分开处理；而 response.status_code == 429 必须触发代理轮换或请求节流，不是简单 sleep 后重发。

对 DNS 失败（socket.gaierror）应优先切换 DNS 解析器或跳过当前 URL
对连接被拒绝（ConnectionRefusedError）大概率是目标服务下线，应标记为永久失效，不再重试
对 503 Service Unavailable 可结合 Retry-After header 决定休眠时长，而非固定值

用 requests.adapters.HTTPAdapter 控制底层重试策略

手动写重试循环容易漏掉连接池复用、SSL 会话保持等细节。正确做法是配置 HTTPAdapter 实例，把重试逻辑下沉到 urllib3 层。注意：默认的 urllib3.Retry 不重试 POST 请求，且对 4xx 状态码默认不重试——这正好符合语义（4xx 是客户端错），但如果你在爬取动态渲染页时遇到 400（因 header 缺失），就得显式开启 status_forcelist=[400, 429, 502, 503, 504]。

from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
<p>retry_strategy = Retry(
total=3,
status_forcelist=[429, 502, 503, 504],
backoff_factor=1,
allowed_methods=["HEAD", "GET", "OPTIONS", "POST"]  # 显式加入 POST
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("http://", adapter)
session.mount("https://", adapter)</p>

如何让爬虫“感知”页面结构变化并自动降级解析

硬编码 soup.select("div.content > p") 的脚本，一旦页面改版就全盘失效。自我修复的关键是分层 fallback：先尝试主选择器，失败则退到语义更宽泛的备选（如 "article p"），再失败则用正则从全文提取段落文本。同时记录每次解析命中率，当连续 5 次 len(soup.select(...)) == 0，就触发“结构漂移告警”，暂停该域名任务并写入日志。

Forge — Python Developer

Python开发助手 — 自动化脚本、API封装、命令行工具、数据管道、网页爬虫。经过测试的代码，包含错误处理和文档。当你需要...

下载

避免用 .find_all("p", class_="text") 这类强绑定 class 的写法；改用 .select("article :is(p, div) > :not(script)")
对 JSON-LD 或 <script type="application/ld+json"></script> 中的结构化数据做兜底提取，这类字段变更频率远低于 HTML
用 lxml.etree.XPath 替代部分 CSS 选择器，XPath 的 contains(@class, "content") 比 CSS 的 .content-text 更耐变化

代理与 User-Agent 的动态闭环管理

静态代理池撑不过半天。真正可用的自我修复是建立“请求 → 响应 → 验证 → 反馈”闭环：每次请求后检查 response.headers.get("X-Cloud-Trace-Id") 是否存在（GCP 服务特征）、response.elapsed.total_seconds() > 15 是否超长、"cloudflare" in response.text.lower() 是否出现防护关键词。任一条件命中，立刻将当前代理 + UA 组合标记为“疑似失效”，后续请求跳过它，并从备用池中加载新组合。

不要依赖第三方 UA 库返回随机字符串——它们往往集中于少数老旧版本。实际有效的是按 Chrome 最新稳定版 UA 模板生成：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/{version} Safari/537.36，其中 {version} 从 chromedriver.chromedriver_version 或公开 API 动态获取。

结构漂移和代理失效这两类问题，往往在日志里只体现为“空结果”或“连接超时”，但根源完全不同。不区分现象背后的机制，所谓自我修复只是把错误延迟抛出而已。