爬虫异常需分层处理：网络层设timeout并检查状态码，解析层预判节点存在性与编码问题，逻辑层断言字段格式并监控反爬特征；统一日志、重试与告警实现可观测性。
爬虫运行时出错很常见，但关键不是“会不会报错”，而是“能不能及时发现、准确定位、自动恢复”。异常检测不是加个 try-except 就完事，它需要分层设计：网络层、解析层、逻辑层都要有对应策略。
网络请求异常：超时、连接拒绝、状态码非200
requests.get() 默认不抛出 HTTP 状态码异常（比如 404、503），必须手动检查。同时，不设 timeout 容易卡死线程。
- 始终显式设置 timeout（如 timeout=(3, 7) 表示 3 秒连通 + 7 秒
读取） - 用 response.raise_for_status() 触发 HTTPError（4xx/5xx）
- 对常见错误分类处理：ConnectionError（DNS失败/无网）、Timeout（慢响应）、TooManyRedirects（跳转环）
- 示例：try: r = requests.get(url, timeout=(3, 10)); r.raise_for_status() except requests.exceptions.Timeout: log.warn("请求超时"); retry_later()
读取）HTML解析异常：标签缺失、结构变动、编码错误
网页改版是爬虫最大天敌。用 BeautifulSoup 或 lxml 提取时，select() 或 xpath() 返回空列表不报错，但后续 .text 或 ['href'] 会触发 AttributeError 或 KeyError。
- 提取前先判断节点是否存在（如 if title_tag := soup.select_one('h1.title')）
- 用 .get() 替代直接取字典键（如 link.get('href', '') 而非 link['href']）
- 对编码问题，优先用 response.content + 指定 parser（如 BeautifulSoup(r.content, 'lxml', from_encoding='utf-8')）
- 记录原始 HTML 片段（如 log.debug(f"缺失标题字段，当前html片段: {soup.body[:200]}")）便于回溯
业务逻辑异常：数据格式突变、反爬拦截、频率越界
这类异常往往不抛错，但结果错得隐蔽。比如价格字段突然从 "¥199" 变成 "9"，或返回了验证码页面却仍被当成正常商品页。
- 对关键字段做格式断言（如 assert re.match(r'^¥\d+', price_text), f"价格格式异常: {price_text}"）
- 检查响应内容是否含反爬特征（如 '请启用JavaScript'、'check' 字样、script 标签含 challenge）
- 监控请求成功率、平均响应时间、HTTP 状态码分布，突降即告警
- 把“成功”定义为：状态码200 + 关键字段非空 + 内容长度 > 阈值（防空白页）
统一异常捕获与可观测性落地
零散的 print 或 log.error 不够。要让异常可聚合、可追溯、可重试。
- 自定义异常类（如 class ParseFailure(Exception): pass），统一抛出，方便上层区分处理
- 每条日志带 trace_id 和 url，便于关联上下游（如 logging.info("parse_title", extra={'trace_id': tid, 'url': url})）
- 用装饰器封装重试逻辑（如 @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10))）
- 关键异常写入本地 error.json 或发到 Sentry，包含：时间、URL、状态码、异常类型、前100字符响应体
基本上就这些。异常检测不是为了消灭错误，而是让错误变得可预期、可管理、可收敛。写爬虫不怕出错，怕的是错得悄无声息。
