你好！在上一篇文章中，我们聊了爬虫代理的基础避坑指南。但随着项目规模的扩大，简单的 try-except 已经无法支撑起高并发、高稳定性的采集需求。如果你的代码里到处充斥着嵌套的重试逻辑，那不仅是维护的噩梦，更是系统脆弱的开始。
今天，我们进入**【设计模式篇】，通过装饰器模式（Decorator）与策略模式（Strategy）**，构建一套既优雅又硬核的代理异常处理框架。
核心设计思想：解耦“逻辑”与“生存”
在设计高可用爬虫时，我们需要将**“业务采集逻辑”与“异常重试策略”**完全解耦。
- 装饰器模式：负责在不侵入业务代码的前提下，动态地为函数增加“防超时、自动重试”的能力。
- 策略模式：负责定义不同的重试算法（如立即重试、指数退避、固定间隔），根据代理的质量动态切换。
实战代码实现
我们将以 Python 为例，利用装饰器封装异常处理，并对接爬虫代理提供的隧道验证。
import time
import random
import requests
from functools import wraps
from requests.exceptions import ProxyError, ConnectTimeout, ReadTimeout
# ==========================================
# 代理配置（亿牛云爬虫代理授权信息）
# ==========================================
PROXY_HOST = "proxy.16yun.cn" #亿牛云代理域名
PROXY_PORT = "6447" #代理端口
PROXY_USER = "16YUN" #代理用户名
PROXY_PASS = "16IP" #代理密码
# 构造代理字典 (符合 requests 标准格式)
PROXIES = {
"http": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}",
"https": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
}
# ==========================================
# 设计模式实现：自愈装饰器
# ==========================================
def retry_strategy(max_retries=3, initial_wait=2, backoff_factor=2):
"""
策略重试装饰器：
使用指数退避策略 (Exponential Backoff)，保护代理链路并降低被封禁风险。
"""
def decorator(func):
@wraps(func)
def wrapper(*args, **kwargs):
retries = 0
wait_time = initial_wait
while retries < max_retries:
try:
# 执行核心采集逻辑
return func(*args, **kwargs)
except (ProxyError, ConnectTimeout, ReadTimeout) as e:
retries += 1
if retries >= max_retries:
print(f"❌ [最终失败] 已重试 {max_retries} 次，异常信息: {e}")
raise # 抛出最终异常供上层处理
# 策略计算：指数增长 + 随机抖动 (Jitter)
# 避免大量请求在同一时间点重试产生的“惊群效应”
sleep_duration = wait_time + random.uniform(0, 1)
print(f"⚠️ [代理异常] 捕获到 {type(e).__name__}，正在进行第 {retries} 次重试，等待 {sleep_duration:.2f}s...")
time.sleep(sleep_duration)
wait_time *= backoff_factor # 增加下一次等待时间
return None
return wrapper
return decorator
# ==========================================
# 业务采集逻辑（极简、纯净）
# ==========================================
@retry_strategy(max_retries=4, initial_wait=3)
def fetch_target_page(target_url):
"""
采集核心函数：不再需要关注如何重试，只需关注如何解析。
"""
# 这里使用亿牛云代理进行请求
response = requests.get(
url=target_url,
proxies=PROXIES,
timeout=5, # 设置严谨的超时阈值
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"}
)
# 状态码校验：如果不是200，我们也视其为需要重试的异常
response.raise_for_status()
print(f"✅ [成功] 响应长度: {len(response.text)}")
return response.status_code
# ==========================================
# 执行入口
# ==========================================
if __name__ == "__main__":
# 模拟一个容易超时的目标网站
TEST_URL = "http://httpbin.org/get"
try:
status = fetch_target_page(TEST_URL)
if status == 200:
print("🚀 任务圆满完成！")
except Exception as final_e:
print(f"💀 系统告警：当前爬虫集群代理链路不稳定，请检查亿牛云余额或网络状态。")
深度解析：为什么这种结构更“优雅”？
1. 关注点分离 (Separation of Concerns)
在上面的代码中，fetch_target_page 函数只关心**“我要抓什么”**。它完全不知道、也不需要知道重试的具体逻辑。这种设计让代码的可维护性提升了几个量级。
2. 引入随机抖动 (Jitter)
在策略模式中，我们不仅使用了指数退避（即等待时间 2, 4, 8...），还加入了 random.uniform(0, 1)。
博主点评： 很多新手会忽略这点。如果你的爬虫是分布式部署，当代理服务短暂波动恢复时，所有的爬虫实例如果都在同一秒重试，会瞬间形成新的流量高峰，导致再次宕机。随机抖动能平滑请求曲线。
3. 精准打击：定向捕获代理异常
注意装饰器中的 (ProxyError, ConnectTimeout, ReadTimeout)。我们并没有鲁莽地捕获所有异常（如 404 或权限错误）。只有当链路出现波动时，重试才有意义；如果是业务代码逻辑错误，重试只会浪费资源。
适合的业务场景
这种设计模式最推荐应用于以下场景：
- 高价值金融数据抓取：每一条数据都不能丢，必须通过多次重试确保采集成功。
- 长周期运行的监控脚本：需要 24 小时无人值守，代理商波动时脚本能“自愈”。
- 企业级爬虫中台：作为底层通用模块，支撑上层数十个业务采集函数。
