多站点并行爬虫实战：反爬策略统一管理与架构设计

1. 项目背景与整体目标拆解1.1 为什么会有“同时爬三个网站”这个需求先说个现实场景。上个月我接到一个数据整合的任务业务方需要把三个不同站点上的商品信息、用户评价和促销活动汇总到一张表里每天定时更新。这三个站点分别是一个电商平台商品SKU和价格每日波动一个行业资讯站发布最新产品动态和评论文章一个公开的图书评论站点用来补充用户口碑数据单看每个站点都不算复杂难点在于“同时”两个字。如果按顺序一个一个爬三个站加起来跑完要将近两个小时中间任何一环断了整个流程就得重来。更麻烦的是每个站点的反爬策略都不一样。有的站看User-Agent有的站盯着请求频率有的站会检测你有没有用浏览器自动化工具。各个击破还好办放到一个项目里统一处理就成了麻烦事。我一开始想着用三个独立的脚本跑结果运维同事直接拒绝了——三套环境、三套日志、三份依赖维护成本翻三倍。后来改成“一个调度器 三套采集器”的方案核心思路就是统一入口、独立鉴权、共享输出。这个方案定了之后后面所有的工作都是围绕这个骨架展开的。1.2 核心目标反爬策略的统一管理这里需要先说清楚一个事我们说的“反爬虫能力”不是说要去攻击哪个网站或者暴力破解人家的安全防护那既不合规也没有必要。实际在做的是在合法抓取公开数据的前提下让自己的采集行为尽量不被反爬机制误伤同时降低对目标站点的访问压力。两个网站交替运行的时候这个问题还不明显。但三个网站同时在跑问题就露出来了每个站点有不同的限速要求有的允许每秒5次请求有的严格到每10秒只能1次三个站点分布在不同的网络区域IP的响应延迟差异很大共用同一个出口IP时如果某一个站点触发封锁可能牵连其他两个站点的采集所以这套系统里“反爬能力”不是指单一的伪装技巧而是一整套访问节奏控制 请求特征管理 异常恢复机制的组合。这也是这个项目里最值得沉淀的部分。2. 方案选型与架构设计思路2.1 多站点采集的三种常见架构对比接手这个项目的时候我脑子里过了三个方案这里直接对比一下给后面做类似需求的朋友做个参考。方案优点缺点适用场景单脚本串行采集实现简单调试方便整体耗时翻倍单点故障直接全挂数据量小、更新频率低多脚本独立运行互不影响故障隔离维护成本高三套依赖环境日志不统一各站点逻辑差异极大无共享需求调度器 多采集Worker统一管理灵活扩缩容日志一致代码结构稍复杂需要设计好接口多站点定期并行采集需要产出统一数据我最终选了调度器多Worker的组合。原因很直接三个站点的采集逻辑虽然各不相同但采集完成后的数据处理流程是一样的包括去重、字段对齐、写入数据库、异常告警。把这些公共逻辑抽出来每个站点只负责“把页面变成结构化数据”整体代码量反而比三个独立脚本加起来更少。另一个考量是扩缩容。业务方说后面可能还要加两个站点如果设计了统一的Worker接口新站点接入只需要写一个采集器类注册到调度器里就完事不需要动主流程。2.2 调度层和采集层怎么划分职责这套架构里最重要的设计就是调度层完全不碰采集逻辑采集层完全不碰数据存储。调度器的职责只有三件事读取配置文件拿到三个站点的启停状态、采集周期、限速参数按配置的周期触发采集任务维护每个站点的下一次运行时间把采集Worker返回的结果放进消息队列交给数据清洗模块处理采集Worker的职责也只有三件事接收调度器下发的任务参数站点标识、起始页、采集范围执行页面抓取、解析、结构化返回一个统一格式的结果对象包含数据列表、成功失败状态、日志摘要这样拆完之后有个明显的好处排查问题的时候先看日志判断是调度没触发还是采集环节报错还是数据清洗出的问题定位速度能快出一大截。实际跑了两周三个站的采集成功率从最初的87%提升到了98.3%这里面架构清晰化的功劳占了很大一部分。2.3 为什么说“会话隔离”是并行爬取的生命线先说一个我踩过的坑。第一版代码里我用了一个全局的requests.Session()对象想着反正都是发HTTP请求共用一个连接池还能省点资源。结果跑起来就傻眼了三个站点的Cookie互相污染A站带上了B站的会话标识B站收到了C站的UA服务器全部返回403甚至有个站点直接封了我们几分钟。这里给新手朋友一个建议千万不要跨站点共享Session。每个站点必须有自己的Session实例单独维护Cookie、Headers和连接池。原因很简单# 错误示范全局共用一个Session session requests.Session() session.headers.update({User-Agent: Mozilla/5.0}) # 三个站点都往这个Session里塞请求互相污染 # 正确做法每站点独立Session site_a_session build_session_for_site(site_a) # 独立Cookie site_b_session build_session_for_site(site_b) # 独立UA site_c_session build_session_for_site(site_c) # 独立代理配置每个会话的UA、Accept-Language、连接超时、重试策略都按目标站点的要求单独配置。后面我会专门讲怎么为每个站点定制请求头。3. 识别反爬机制与常见封禁逻辑3.1 第一道坎请求头特征检测多数站点的第一道反爬防线就是检查HTTP请求头。别小看这个三个站点我就见了三种玩法。第一个站点检查的是User-Agent的完整性和浏览器一致性。普通浏览器UA长这样Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36如果你用默认的python-requests/2.31.0一眼就能被识别出来。解决方法也简单准备一个UA池每次请求随机轮换。但光有UA还不够第二个站点会检查User-Agent和实际浏览器行为是否匹配比如你声称是Chrome但Accept-Language的顺序不对或者Sec-Fetch-Mode值不合规范照样会被标记。第三个站点更精它看的是TLS指纹。HTTP层伪装做得再好底层TLS握手特征还是会暴露requests库的加密套件组合。这个问题后面对付的办法是用curl_cffi这个库模拟浏览器TLS指纹实测通过率提升了不少。3.2 第二道坎频率控制与IP维度封锁频率控制大概是“多站并行”场景下最难受的问题。我试过把三个站的请求间隔都设为2秒结果A站和B站没问题C站的日志里疯狂出现429状态码。去看了C站的robots.txt和响应头才发现它的缓存策略是滑动窗口限流10秒内超过10个请求就锁定。后面总结了一套规避频率限制的配置策略直接做成配置文件sites: site_a: request_interval: [1.5, 3.0] # 随机间隔范围秒 max_retries: 3 # 失败重试次数 retry_backoff: [5, 15] # 重试等待时间范围秒 site_b: request_interval: [3.0, 6.0] max_retries: 2 retry_backoff: [10, 30] site_c: request_interval: [8.0, 12.0] # 这个站管得严必须慢 max_retries: 5 retry_backoff: [30, 60]关键点在于用random.uniform()生成一个随机区间而不是写死一个固定间隔。固定间隔会被速率计算器识别成“机器行为”随机抖动反而是最接近人类浏览模式的做法。IP层面的封锁是另一个大坑。三个站同时跑的时候尤其注意不要用一个IP高频访问多个不相关域名。专业的做法是给不同的目标站配置不同的出口IP或至少分散成不同网段。不过考虑到成本我实际项目里用的是动态代理池方案按站点维度分配代理组。3.3 第三道坎浏览器自动化检测以Selenium为例项目里有个站点需要执行JavaScript才能渲染数据被迫用了Selenium。结果没过多久就被检测到了报错提示非常明显“ChromeDriver is being controlled by automation”。这里涉及一个概念叫“浏览器指纹检测”。就算你用Selenium打开一个真实的Chrome实例对方网站也可以通过以下特征判断出这是自动化工具navigator.webdriver属性为true浏览器窗口的尺寸异常或者没有真实显示器的刷新率JavaScript执行环境中存在ChromeDriver注入的变量我当时的处理方式是组合拳from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() # 关闭自动化控制标志 options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False) # 隐藏webdriver特征 options.add_argument(--disable-blink-featuresAutomationControlled) # 设置真实的UA options.add_argument(user-agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36) # 设置窗口大小 options.add_argument(--window-size1920,1080) driver webdriver.Chrome(optionsoptions) # 覆盖webdriver检测点 driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, { source: Object.defineProperty(navigator, webdriver, {get: () undefined}) })这一套操作之后Selenium被识别的风险大大降低了。不过要注意的是这只适用于轻量级的检测。遇到那种有行为验证码的站点要求拖动滑块、点选文字Selenium还是很难完美通过这类站点我的建议是评估一下投入产出比或者考虑接第三方打码服务。4. 实操环节三站并行的代码实现全记录4.1 前置基础统一的任务模型与接口在上代码之前先说清楚整个工程里最关键的一个设计——采集任务的统一模型。无论目标是商品页、文章页还是评论页最后都要转成同一种结构才能走后续的清洗入库流程。# task_model.py from dataclasses import dataclass, field from typing import Optional, Dict, List import time dataclass class CrawlTask: site_name: str # 站点标识site_a / site_b / site_c task_type: str # 任务类型list / detail / search url: str # 请求地址 priority: int 5 # 优先级数字越小越先执行 created_at: float field(default_factorytime.time) retry_count: int 0 extra: Dict field(default_factorydict) # 存放站点特有参数 def __repr__(self): return fCrawlTask site{self.site_name} type{self.task_type} url{self.url[:50]} dataclass class CrawlResult: site_name: str task_type: str data: List[Dict] ok: bool error_msg: Optional[str] None elapsed: float 0.0 # 本次抓取耗时 response_code: int 0 # 原始HTTP状态码 def to_dict(self): return { site_name: self.site_name, task_type: self.task_type, ok: self.ok, error_msg: self.error_msg, elapsed: self.elapsed, response_code: self.response_code, data_count: len(self.data), }这个模型是三个Worker共用的。每个站点写一个采集类实现同样的接口class BaseCrawler: site_name None def __init__(self, session: requests.Session, config: dict): self.session session self.config config def fetch(self, task: CrawlTask) - CrawlResult: raise NotImplementedError def parse(self, html: str) - List[Dict]: raise NotImplementedError这样后面扩展新站点就只需要继承BaseCrawler实现fetch和parse两个方法就完事了。4.2 调度器核心代码调度器规划周期用的是schedule库每次到点就给目标Worker投递一个任务。由于三个站点频率不同我的做法是为每个站点建一个独立的任务队列互不阻塞。# scheduler.py import schedule import time import queue from concurrent.futures import ThreadPoolExecutor from task_model import CrawlTask task_queues { site_a: queue.Queue(), site_b: queue.Queue(), site_c: queue.Queue(), } def enqueue_site_a_job(): task_queues[site_a].put( CrawlTask(site_namesite_a, task_typelist, url...) ) schedule.every(30).minutes.do(enqueue_site_a_job) schedule.every(2).hours.do(enqueue_site_b_job) schedule.every(6).hours.do(enqueue_site_c_job) executor ThreadPoolExecutor(max_workers3) def worker_loop(site_name): while True: task task_queues[site_name].get() crawler get_crawler_instance(site_name) # 每个Worker持有自己的Session result crawler.fetch(task) handle_result(result) # 写入队列交给清洗模块 for site in task_queues: executor.submit(worker_loop, site) while True: schedule.run_pending() time.sleep(1)在这个调度器基础上我后来又加了暂停/恢复某站点任务的逻辑。比如某个站点连续返回3次500状态码调度器会自动把该站点的入队操作暂停30分钟期间其他两个站不受影响。4.3 定制三套请求头策略这一步是“反爬能力”的核心体现。三个站点的请求头策略是完全不同的这来自于我们对每个站点检测逻辑的逆向分析。这里放一份实际项目中的配置脱敏后供参考。站点User-Agent关键Header频率策略site_a固定一个Chrome UAReferer必填1.5~3秒随机site_bUA池随机轮换Accept-Language需与UA匹配3~6秒随机site_c模拟移动端UASec-Fetch-* 全套补齐8~12秒随机优先走代理请求头的整体封装逻辑def build_headers(site_name: str) - dict: base_headers { Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Connection: keep-alive, Upgrade-Insecure-Requests: 1, Sec-Fetch-Dest: document, Sec-Fetch-Mode: navigate, Sec-Fetch-Site: same-origin, } if site_name site_a: base_headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://site-a.com/, }) elif site_name site_b: base_headers.update({ User-Agent: random.choice(UA_POOL), Referer: https://site-b.com/news/, }) elif site_name site_c: base_headers.update({ User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1, X-Requested-With: XMLHttpRequest, }) return base_headers4.4 反爬增强随机延时、重试退避与请求签名这是整个项目里我最想沉淀的一章。三个站点的抓取成功率能提升到98%以上靠的就是这三板斧。随机延时原理很简单人类浏览网页的速度是不均匀的。看一篇文章停五秒下一秒点下一页只隔了一秒。机器的请求间隔往往是均匀的哪怕是1.5秒也是均匀的1.5秒。所以我们要让请求间隔在一个范围内抖动。import random import time def smart_delay(site_name: str, config: dict): min_s, max_s config[site_name][request_interval] if random.random() 0.3: # 模拟阅读停顿偶尔来个长间隔 time.sleep(random.uniform(max_s * 1.5, max_s * 2.5)) else: time.sleep(random.uniform(min_s, max_s))我在实际运行中观察了一下加了这30%概率的长停顿之后被限流的次数明显变少了。因为服务端的速率检测通常是按滑动窗口计算的偶尔的长间隔能有效打破“匀速机器”的统计学特征。重试退避请求失败之后的重试一定不能立刻重发。业界通用的做法是“指数退避”每次重试的等待时间是上一次的两倍。举例第一次失败后等3秒第二次失败后等6秒第三次失败后等12秒最多不超过配置里的上限。def fetch_with_retry(session, url, headers, config): max_retries config[max_retries] backoff config[retry_backoff] for attempt in range(max_retries 1): try: response session.get(url, headersheaders, timeout10) if response.status_code 200: return response if response.status_code in (403, 429): wait min(backoff[1], backoff[0] * (2 ** attempt)) log.warning(f被限流/拒绝{response.status_code}, 等待 {wait}s 后重试) time.sleep(wait) continue # 其他状态码直接返回不浪费重试机会 return response except requests.RequestException as exc: wait min(backoff[1], backoff[0] * (2 ** attempt)) log.warning(f网络异常{exc}, 等待 {wait}s 后重试) time.sleep(wait) log.error(f已重试 {max_retries} 次仍失败放弃请求: {url[:100]}) return None请求签名有些站点的接口带了签名参数比如?ts1699999999signabc123。这个签名是服务端用固定算法通常是加盐后的MD5或HMAC生成的参数一旦变动签名就校验失败。针对这类站点我的做法是先抓包分析调用链找出签名生成的规律。一般有两种出路如果签名算法简单比如md5(urltimestampsalt)可以在代码里复现如果算法复杂或者带了动态token就需要先用Selenium加载一次页面拿到token再带着token去请求数据接口这里重点提醒一句签名逆向有合规风险只应在明确授权和合法用途下进行。我项目里遇到的是第一种情况站点提供方自己公开了接入文档所以直接按文档生成就行了。4.5 三个站点的Worker实现细节站点A列表页详情页串行拉取A站的数据分布在列表页和详情页两层。列表页抓完拿到商品ID列表再逐条抓详情页。注意详情页频率要更低因为详情页是真实的付费接口访问消耗也更大。class SiteACrawler(BaseCrawler): site_name site_a def fetch(self, task): if task.task_type list: return self._fetch_list(task) if task.task_type detail: return self._fetch_detail(task) def _fetch_list(self, task): headers build_headers(site_a) response self.session.get(task.url, headersheaders, verifyFalse) data self.parse(response.text) return CrawlResult( site_nameself.site_name, task_typetask.task_type, datadata, okTrue, response_coderesponse.status_code, ) def parse(self, html): # 用BeautifulSoup解析列表页 # 返回包含商品ID、名称、价格字段的dict列表 pass站点B动态渲染页面技术栈升级到PlaywrightB站前端用了比较多的AJAX请求用requests直接拉HTML看不见数据。一开始我以为要上Selenium后来考虑到性能和数据量换成了Playwright。# crawler_b.py from playwright.sync_api import sync_playwright def fetch_with_playwright(url, user_agent): with sync_playwright() as p: browser p.chromium.launch( headlessTrue, args[--disable-blink-featuresAutomationControlled] ) context browser.new_context( user_agentuser_agent, viewport{width: 1920, height: 1080}, localezh-CN, ) page context.new_page() page.goto(url, wait_untilnetworkidle) html page.content() browser.close() return htmlPlaywright相比Selenium的优势是自带更完善的浏览器上下文管理每次打开页面都是干净的上下文不容易被检测到上一个页面的残留状态。站点C登录态维护与Cookie策略C站有部分数据需要登录后才能看到。这里不涉及任何破解只是正常注册账号后维护自己的登录态。核心思路是把登录后的Cookie落盘保存下次启动时直接带上避免每次都走一遍登录流程。# cookie_manager.py import json import os COOKIE_FILE { site_a: cookies/site_a.json, site_b: cookies/site_b.json, site_c: cookies/site_c.json, } def save_cookies(session, site_name): cookies session.cookies.get_dict() with open(COOKIE_FILE[site_name], w) as f: json.dump(cookies, f) def load_cookies(session, site_name): if not os.path.exists(COOKIE_FILE[site_name]): return False with open(COOKIE_FILE[site_name]) as f: cookies json.load(f) session.cookies.update(cookies) return TrueCookie是有时效性的通常一周到一个月不等。我加了一个定时任务每周重新登录一次刷新Cookie避免突然失效导致整条采集链路中断。这个操作看着简单但在并行采集里特别关键因为一个站的Cookie过期了另外两个站还在正常跑日志里会出现“有的站数据正常有的站突然全是空”的假象排查起来很费劲。4.6 数据清洗与统一入库三套Worker的产出格式虽然统一成了List[Dict]但各站点的字段名不一致。比如“标题”这个字段A站叫product_nameB站叫article_titleC站叫review_title。清洗模块的作用就是把这些字段名映射成统一的业务字段。# transformer.py FIELD_MAPPING { site_a: { product_name: title, price: amount, product_url: source_url, }, site_b: { article_title: title, publish_time: pub_time, }, site_c: { review_title: title, rating: score, }, } def normalize_data(site_name: str, raw_data: List[Dict]) - List[Dict]: mapping FIELD_MAPPING[site_name] normalized [] for item in raw_data: new_item {} for raw_key, new_key in mapping.items(): if raw_key in item: new_item[new_key] item[raw_key] normalized.append(new_item) return normalized清洗完之后写入数据库的逻辑就比较常规了用SQLAlchemy批量upsert按业务主键去重避免重复写入。每天跑完看一次统计报表哪个站抓了多少条失败了多少条一目了然。5. 常见问题与排查技巧实录5.1 高频报错排查手册几个月的运行下来我把遇到的高频问题整理成了速查表按排查优先级排列症状可能原因排查手段某个站点全部返回403IP被站点风控或UA被拉黑换出口IP清理该站点的Session检查Referer请求返回200但缺少目标数据数据被JS动态加载请求的静态HTML里没有用Playwright渲染或找XHR接口直接抓JSON偶发429状态码请求频率超限加大随机间隔增加重试退避时间三个站同时失败出口网络中断或代理池全局失效先中断所有任务检查代理健康后重启调度器某个站点数据突然全是空列表Cookie过期登录态失效查看站点配置的最近一次Cookie刷新时间重新登录抓下来的字段有乱码编码判断出错页面是GBK但用UTF-8解析根据响应头charset指定解析编码或者用chardet自动检测5.2 并行环境下的Session安全我在开发中不止一次被Session问题坑过。多线程环境下多个Worker共用全局Session对象时requests库虽然做了线程锁但Cookie的读写顺序没有保证容易出现偶发的脏数据。实际项目中直接在全局断言做了防护assert CrawlerA.session is not CrawlerB.session assert CrawlerA.session is not CrawlerC.session这种断言放在初始化阶段跑测试的时候能自动暴露问题。另外还有一个建议每个Worker的Session实例不要跨任务复用太久建议每处理500个请求就重建一次Session。这样即使站点暗中埋了Cookie追踪也会被定期“断尾”。5.3 监控与日志并行爬虫的第三只眼三个站并行跑没有监控等于盲人摸象。我这边配了一套比较轻的监控方案日志统一输出到三个文件site_a.log、site_b.log、site_c.log——每个Worker写自己的日志问题和站点一一对应每完成一个批次任务把结果统计写入tasks_status.json包括成功数、失败数、平均耗时、错误码分布失败率超过10%时推送告警到微信群日志推荐用structlog或者标准库logging配合JSON格式化让每条日志都带站点名、任务类型、耗时、状态码这几个维度排障时能精准过滤。我自己养成了一个习惯每天午休前盯着看10分钟日志滚动检查三个站的处理进度。哪站慢了自己心里就有数等告警出来再去处理往往已经晚了。6. 实测数据复盘与关键经验沉淀6.1 一组真实运行数据的复盘项目稳定运行一个月之后的统计数据如下三站全口径指标数值日均抓取请求数大约2.1万次平均成功率98.3%三站并行总耗时从2小时缩减到约55分钟被封IP次数0次未主动访问受限内容单过程序崩溃恢复3次均为网络中断导致手动重启后恢复这个成功率并不是白来的。单一的“慢速爬”并不能解决全部问题真正提成功率的是把每个站点的“个性”摸透然后有针对性地配置请求策略并且让三个站点的运行互不干扰。另外说一个细节从2小时缩减到55分钟其实不是因为把并发开大了而是因为三站并行后调度器可以按站点的空闲时间穿插任务把时间碎片利用起来了。一个站在等待重试的时候另一个站已经在抓下一页了整体效率提升就是这么来的。6.2 我踩过的三个“经典天坑”第一个天坑全局异常捕获把403当成功处理。第一版代码里状态码只要不是500就认为成功结果403页面被当成正常数据入库。清洗后的表里全是“访问被拒绝”几个字。后来在解析前校验了页面内容的长度和关键词低于阈值的直接抛异常。第二个天坑并发数量开太多反而更慢。我试过把三个Worker各开5个线程15个线程同时跑。结果目标站的反爬机制检测到高并发直接把整个IP段限流了本来55分钟能跑完的数据跑了3个小时。后来改成每个Worker保持单线程或者最多双线程再加上全局线程池只开3个Worker反而是最快的。原因是服务端的限流是“宁可错杀不可放过”只要触发了阈值整体吞吐量会断崖式下跌。第三个天坑爬取结果不做去重导致数据膨胀。三个站本来就有数据重叠的部分比如A站和C站都收录了某本书的评论。如果只是简单合并表里的重复记录会越攒越多。后来加了基于URL标题的联合唯一键配合SQL的ON CONFLICT DO UPDATE完美解决。6.3 一个小技巧给每个Worker配“心跳”最后分享一个实战里特别管用的小东西给每个Worker加一个心跳线程每60秒向调度器上报一次“我还在运行当前进度XX”。调度器如果连续3分钟收不到某个Worker的心跳就自动重启该Worker对应的任务队列。这个功能实现成本很低但排障价值非常大。之前有一次调度器误判了任务完成状态导致某个站停跑了一个周末数据缺口两天才发现。有了心跳这类问题最多延迟5分钟就能被自动发现并拉起来。7. 从“采得到”到“采得稳”的几点心得说到底“反爬虫能力”不是某个单一技巧而是一整套系统工程。这套系统在三个站点并行的高压场景下被验证过也踩过不少坑我把最核心的心得浓缩成下面这几条。第一了解目标站点的规则永远比研究对抗更重要。有反爬机制的站点大部分都有公开的接口文档或数据协议。优先走正规渠道既安全又省心。真到了必须“友好采集”的层面也要严格控制频率时刻把“不打扰目标站点正常服务”当作底线。第二配置化比硬编码更抗风险。站点的反爬策略是动态变化的可能这周还行下周就改了。把请求头、频率、重试参数全部外置到配置文件改动的时候只改配置不动代码系统才能活得久。第三监控数据是排障的核心依据。把每一条请求的响应码、耗时、结果数量记录下来哪怕只是存文本。出问题的时候回看监控数据比瞎猜高效得多。第四并行爬虫的根本不是“快”而是“稳”。三个网站同时跑稳定压倒一切。频率调低一点没关系关键是别把整个IP打没了别让数据链路断掉。我见过太多入门者盲目追求高并发结果第二天就被目标站“请喝茶”。稳扎稳打数据在手这才是长久之计。