如果你维护过一段时间的采集系统，大概率会经历这样一个阶段：
一开始一切都很顺利，requests 一跑，数据就回来了。
后来目标站点开始限速，你加了代理。
再后来，403、429、超时轮番出现，报警开始刷屏。
系统并不是完全不可用，但你发现一件很烦的事——
它越来越依赖人工去“盯着”。
这时候，很多人都会隐约意识到一个问题：
问题不在某一次失败，而在系统没有“自救能力”。
这篇文章想聊的，就是采集系统从“失败就报错”，到“失败先尝试修复”的那一步演进。
一点技术背景：为什么现在的爬虫更容易出问题
早些年的采集系统，其实并不需要太复杂的设计。
请求成功率高，限制手段也相对简单，失败更多来自网络抖动。
但这几年情况明显变了：
- 反爬策略开始动态化
- 同一 IP 的可用时间越来越短
- 行为模式比请求参数更重要
- 成功率开始随时间波动，而不是线性下降
在这种环境下，如果采集系统的行为是“固定的”，那它迟早会撞上墙。
于是，一个很现实的问题摆在面前：
我们是继续靠人工救火，还是让系统自己先试着修一修？
从三个常见方案说起
在大多数团队里，采集系统通常会经历三个阶段。
第一阶段：最基础的采集
这一阶段的目标只有一个：能拿到数据。
代码往往很简单，请求一次，失败就重试几次，实在不行就记日志。
在低频、临时任务里，这种方式没有任何问题。
但一旦采集变成长期任务，失败就会慢慢变成常态，而不是例外。
第二阶段：加了一点“防御”的采集
当失败开始增多，大家通常会做几件事：
- 加代理
- 加重试
- 稍微降点速
这套方案能明显延长系统的寿命，也是很多线上系统停留的状态。
但你很快会发现，它有一个问题：
系统并不知道自己为什么失败。
于是你开始反复遇到这样的场景：
- 同样的错误，不停地重试
- 同一批代理，在失效边缘反复使用
- 人工不停调整参数，却很难一劳永逸
第三阶段：让系统具备“自我修复”的能力
所谓自我修复，并不是系统突然变得很智能，而是它开始做一件很简单的事：
先判断发生了什么，再决定怎么应对。
比如：
- 超时了，是不是该等一等
- 返回 403，是不是该慢一点
- 代理异常，是不是该暂时放弃这条线路
当系统开始有这种“分情况处理”的意识时，它的稳定性会出现一个质的变化。
用代码看一下差别
先看一个最常见的请求写法。
importrequestsdeffetch(url):try:resp=requests.get(url,timeout=5)resp.raise_for_status()returnresp.textexceptExceptionase:print("请求失败：",e)returnNone这种代码本身没有问题，但它的能力边界非常清晰：
- 不关心失败原因
- 不调整行为
- 失败一次，就算一次
这也是为什么它很难支撑长期运行。
再看一个“会尝试自救”的版本
下面这个例子，用的是亿牛云爬虫代理的配置方式，主要想表达一种思路，而不是具体实现细节。
PROXY_HOST="proxy.16yun.cn"PROXY_PORT="31111"PROXY_USER="username"PROXY_PASS="password"proxy_url=f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"proxies={"http":proxy_url,"https":proxy_url}接下来是请求逻辑。
importrequestsimporttimeimportrandomdefsmart_fetch(url,max_retry=5):forattemptinrange(1,max_retry+1):try:headers={"User-Agent":random.choice(["Mozilla/5.0 (Windows NT 10.0; Win64; x64)","Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)","Mozilla/5.0 (X11; Linux x86_64)"])}timeout=random.uniform(3,8)resp=requests.get(url,headers=headers,proxies=proxies,timeout=timeout)ifresp.status_codein(403,429):time.sleep(attempt*2)continueresp.raise_for_status()returnresp.textexceptrequests.exceptions.Timeout:time.sleep(attempt)exceptrequests.exceptions.ProxyError:time.sleep(2)exceptException:time.sleep(1)returnNone这段代码并没有做什么“高深”的事情，但它已经具备了一些重要特征：
- 失败不会立刻放大
- 行为会随失败而变化
- 系统会给自己留出缓冲空间
这正是“自我修复雏形”的核心。
什么时候真的有必要做到这一步？
坦白说，并不是所有采集任务都值得上这种复杂度。
如果你只是：
- 临时抓点数据
- 采集频率不高
- 目标站点反爬很弱
那简单方案反而更合适。
但如果你遇到的是：
- 长时间运行的采集任务
- 成本不低的代理资源
- 反爬策略经常变化
- 人工维护已经成负担
那你大概率已经站在“要不要自我修复”的门槛上了。
最后一点个人感受
很多人谈稳定性时，会不自觉地追求“永不失败”。
但真实世界里的系统，很少有这种奢侈条件。
对我来说，更现实的目标是：
失败是允许的，但它不应该失控。
当采集系统开始尝试理解失败、消化失败、缓解失败时，
你会明显感觉到一件事：
系统没那么脆了，人也轻松了。
而这，往往是一个采集系统真正成熟的开始。
