我做了三年多的爬虫接过的项目从几十个页面的小脚本到千万级数据量的采集系统都有。说实话市面上讲爬虫的教程多得是但真正能把“多线程”和“代理IP”这两个东西讲透、讲明白怎么组合起来用的还真不多。前几天还有个朋友问我为什么他的爬虫程序加了ThreadPoolExecutor之后反而被封得更快了我一问才知道他为了赶进度把线程数拉到100代理IP还是从免费网站抠来的那批。这个组合不出问题才怪。这篇就从实际操作的角度把Python多线程爬虫和代理IP配套使用的完整思路、代码细节、参数调优、踩坑记录一次性聊清楚。不管你是刚入门想进阶还是已经写了几个项目但性能一直上不去这篇都值得看完。1. 慢在哪、封在哪先搞懂爬虫性能的两个瓶颈1.1 等而不是算爬虫为什么天生适合多线程很多人刚开始学爬虫的时候写的代码长这样import requests urls [https://example.com/page/1, https://example.com/page/2, ...] for url in urls: resp requests.get(url) parse(resp.text)逻辑没问题但跑起来就知道有多煎熬。几百个URL一个接一个地请求每个请求最少也要几百毫秒到一两秒的响应时间。算下来一百个页面怎么也要一两分钟。问题出在哪大部分时间都花在“等”上——等待服务器响应、等待网络传输、等待DNS解析。这个“等”的过程里CPU几乎什么都没做纯粹在睡大觉。这就是爬虫区别于普通计算任务的本质特征它是I/O密集型任务不是CPU密集型任务。计算密集型任务要靠提升CPU利用率来加速而爬虫这种场景百分之九十以上的时间都消耗在I/O等待上。既然CPU在闲着那就多开几条线程让它们在等待的同时继续发出新的请求这就是多线程带来性能提升的理论基础。用生活化的例子来说单线程爬虫就像一个人去菜市场买菜买完一根萝卜回家送回去再出门买一根白菜再送回去。多线程就像一个买手团队每个人负责一类食材大家同时出门效率自然翻了不止一倍。1.2 线程数不是越大越好GIL和其他现实约束Python有一个绕不开的话题——GIL全局解释器锁。这个锁保证同一时间只有一个线程在解释器中执行Python字节码。所以很多刚接触Python多线程的人会问既然有GIL那多线程还有意义吗答案是有没有意义取决于你的任务类型。如果是纯CPU密集型任务比如做图像处理、大规模数值计算Python多线程受GIL限制性能提升非常有限这种场景应该用多进程或者直接上asyncio配合底层C库。但对于爬虫这种I/O密集型任务请求发出后线程就阻塞在recv上此时GIL会被释放别的线程就能继续执行。换句话说多线程在爬虫里是真的能抢到并发执行效果的。但线程数也不是随便拍脑袋定的。我在实际项目里踩过一个大坑为了赶进度把线程数拉到200结果对方服务器直接返回了403最后整个IP段被封了。线程数太大一方面容易触发服务器的反向代理检测策略另一方面线程的创建、上下文切换也会消耗资源线程太多反而导致总吞吐量下降。关于线程上限的设定我需要先说明两个维度一个是安全维度。目标网站的反爬策略、单IP限流阈值、请求频率要求这些直接决定了你能跑多激进。另一个是性能维度。线程数不是越多越好因为线程调度有开销目标服务器接收能力也有限。建议从较小的值开始测试比如min(50, 目标站点的合理的并发上限)观察响应时间和错误率再缓慢往上加。一般来说单机、单IP的场景合理的线程数范围在16到64之间具体取决于目标网站的承受能力和你的代理IP池的健康程度。1.3 为什么一定要把代理IP放进方案里多线程解决的是“慢”代理IP解决的是“被限制”。很多人以为代理IP只是为了“隐藏自己的IP”这个理解太肤浅了。在真实的爬虫场景里代理IP的价值至少有三层。第一层是规避IP级别的限速和封禁。大多数网站的反爬策略都是基于IP维度的比如单个IP的每秒请求数限制、单位时间内的访问总量限制。多线程一开单IP的请求频率蹭蹭往上涨触发封禁是迟早的事。代理IP相当于给你提供了多张“通行证”把请求分散到不同IP上自然绕开了单IP的频控。第二层是数据准确性。很多网站尤其是电商、旅游类站点会根据IP归属地返回不同的内容。比如同一个商品上海IP和北京IP看到的价格可能不一样。如果你的爬虫要采集多城市的价格数据就必须用对应的地区代理IP。第三层是业务稳定性。爬虫任务往往是长期运行的比如每五分钟采集一轮价格、每小时同步一次库存。如果你只用本机IP跑一旦被识别并封禁整个数据管道就断了。代理IP池相当于给系统加了冗余单个IP挂掉不影响整体任务继续跑。2. 多线程爬虫的正确打开方式从ThreadPoolExecutor到线程安全2.1 线程池比手写线程好在哪里初学者喜欢这么写多线程import threading threads [] for url in urls: t threading.Thread(targetscrape, args(url,)) t.start() threads.append(t) for t in threads: t.join()这个写法最大的问题是线程池不受控。一次性把所有任务都创建成线程任务多的时候可能创建几百上千个线程系统资源被迅速耗尽目标服务器也会瞬间收到大量请求——基本就是在告诉对方“快来封我”。更稳的做法是使用concurrent.futures.ThreadPoolExecutor。线程池会维护固定数量的工作线程把任务放进内部队列Worker不断从队列里取任务执行。这样做的好处有三个线程数量可控可以通过max_workers参数精确控制并发度。任务提交方便用submit方法提交单个任务也可以直接用map批量提交。获取结果简单future.result()可以直接拿返回值不需要手动管理线程间的通信。一个标准的线程池爬虫核心逻辑长这样from concurrent.futures import ThreadPoolExecutor, as_completed def fetch_url(url): try: resp requests.get(url, timeout10) resp.raise_for_status() return url, resp.text except Exception as exc: return url, exc with ThreadPoolExecutor(max_workers16) as executor: future_map {executor.submit(fetch_url, url): url for url in urls} for future in as_completed(future_map): url future_map[future] try: url, result future.result() except Exception as exc: print(f{url} generated an exception: {exc})注意我用了一个future_map来保存URL和Future对象的映射关系。这样在as_completed遍历结果时可以精准定位到具体是哪个URL执行完了方便做日志记录和失败重试。2.2 线程安全与数据共享别让变量到处乱飞多线程的另一个经典陷阱是共享变量冲突。想象这个场景你有一个全局计数器用来统计成功抓取了多少个页面主线程每隔几秒打印一次进度。你开心地写着global_count 0 def worker(url): global global_count resp requests.get(url) parse(resp.text) global_count 1这个global_count 1在多线程环境下就是典型的竞态条件。虽然Python的GIL在一定程度上减少了纯Python操作发生数据竞争的概率但这个操作实际上包含“读取、计算、写回”三个步骤线程可能在任何一步被切走导致计数丢失。解决方式有两个层面。第一个层面如果是简单的计数器直接用threading.Lock包一下import threading lock threading.Lock() global_count 0 def worker(url): global global_count resp requests.get(url) parse(resp.text) with lock: global_count 1第二个层面如果数据结构更复杂比如多个线程需要向同一个列表或字典写入结果推荐用queue.Queue作为数据中转站。Queue内部实现了线程安全机制自带锁不需要你自己再加。Worker线程把结果放进队列主线程或单独的写入线程从队列里取数据再批量化写入文件或数据库。这样既解耦了生产者和消费者又避免了锁的滥用。2.3 多线程爬虫的性能调优找到你的黄金并发值很多读者会问max_workers到底设置多少合适这个问题没有标准答案但有一套可行的推断方法。核心指标是单个IP的请求间隔和单次请求的平均耗时。假设目标网站允许单个IP每秒最多请求N次你的单个请求平均耗时是T秒。那么单IP的理论最大并发值约为N * T。举个例子如果目标网的频控大约是每秒5次而你的单次请求平均耗时0.5秒那么并发值可以定在5 * 0.5 3左右。这个数值保证在任何一秒内发出的请求不会超过频控限制。但如果你同时使用了代理IP池有多个代理IP在帮你分流那并发值就可以乘以代理IP的数量。这也是为什么代理IP和多线程是一对黄金搭档——代理IP池越大多线程的并行上限就越高。实际操作时我一般建议这样起步先用max_workers1跑一分钟记录单次请求的平均耗时和失败率。逐渐调高到4、8、16每档跑一两分钟观察总吞吐量和HTTP错误率的变化。当错误率开始明显上升说明频控或防护开始生效。这时的并发数再打一个七到八折就是当前代理池配置下的安全并发值。3. 代理IP池设计与选型IP是越贵越好吗3.1 代理类型对比该用透明、匿名还是高匿代理代理IP之间也有很大区别主要按照匿名程度分成三类。透明代理服务器能检测到你在使用代理并且能看到你的真实IP。这种代理在爬虫场景基本没有防护能力只能用来访问一些完全不设防的站点。普通匿名代理服务器能检测到代理的存在但看不到你的真实IP。这类代理适合一些轻度反爬的网站但对某些严格的指纹检测还是会被识别。高匿名代理服务器既检测不到代理的使用痕迹也看不到真实IP。在目标服务器的视角里请求就像来自一个普通用户的真实网络环境。大部分严肃采集场景都需要高匿代理。除了匿名等级代理IP还有两种使用模式。一种是短效动态代理每次请求或每几分钟更换一个新IP。适合大规模采集、对IP时效性要求高的场景电商价格监控、舆情监测、批量抓数据这类任务用得最多。另一种是隧道代理你只需要对接一个固定地址代理服务商在后台自动帮你轮换IP。客户端不需要自己管理IP列表代码更简洁稳定性更好但单价也更高。我个人的建议如果只是学习、调试用隧道代理最省心。如果是生产环境且技术能力允许短效动态代理配合本地代理池灵活性和成本控制都更好。好的接下来我把代理IP和代码结合的具体方案展开说。3.2 自建代理池还是买现成的API这里要看你的预算和人力。自建代理池的完整链路是爬取免费代理 - 校验可用性 - 存储 - 调度分配。看上去很酷但免费代理的可用率通常只有百分之几到百分之十几而且稳定性极差采集过程中随时可能IP失效。爬虫代码还没写多少代理池的维护代码已经一大堆了。买现成的代理API则简单得多。一般代理服务商都提供API接口你只需要从接口拿IP塞给requests的proxies参数即可。国内比较成熟的服务商都能做到秒级切换IP、全国地区定向、按量计费。唯一的缺点是花钱但相比自建代理池所投入的时间和服务器成本通常还是划算的。如果你打算走API这条路我建议留意代理IP的存活时间是多长。短效代理是按次计费还是按时间计费对代码设计影响很大。是否支持指定地区。多城市数据采集必须支持。接口返回的IP是否已经去重以及生效时间是即时还是需要等待一段时间。是否支持批量提取。一次提取多个IP能减少API调用次数降低被限流的风险。这里需要说明一下不同服务商的产品规则差异很大具体接入方式要以你选用的服务商文档为准。下面给出的逻辑是一套通用的轮换方案设计思路核心思想是“缓冲对列 定期刷新 失败剔除”。3.3 让代码自己管理代理一个轻量级代理池实现我自己写爬虫时从来不直接在生产代码里硬编码代理IP。原因很简单代理IP有生命周期短效代理可能几分钟就失效了写死了就意味着频繁改代码。我的做法是在项目里维护一个轻量的代理池模块。核心思想是一个线程负责定期从API拉取新IP另一个负责从队列里取IP供爬虫使用爬虫用完归还如果IP失效则直接丢弃。import queue import threading import time import requests class ProxyPool: def __init__(self, fetch_func, min_size10, max_size50): self._pool queue.Queue(maxsizemax_size) self._fetch_func fetch_func self._min_size min_size self._lock threading.Lock() def start(self): threading.Thread(targetself._refill_loop, daemonTrue).start() def _refill_loop(self): while True: with self._lock: if self._pool.qsize() self._min_size: new_proxies self._fetch_func(self._min_size - self._pool.qsize()) for proxy in new_proxies: try: self._pool.put_nowait(proxy) except queue.Full: break time.sleep(5) def get_proxy(self): try: return self._pool.get(timeout3) except queue.Empty: return None def remove_proxy(self, proxy): with self._lock: try: # 重新填充弥补失效代理造成的空缺 self._pool.task_done() except ValueError: pass这个实现的好处是爬虫主逻辑不需要关心代理从哪来、什么时候过期只需要get_proxy拿IP失效了就remove_proxy通知池子补充新IP。整体耦合度很低。我个人的做法是把获取新IP的操作封装成一个fetch_func这样既可以接付费代理API也可以接自建的免费代理采集脚本。想换供应商的时候只需要改几行代码。建议你根据自己的情况灵活调整如果市面API的返回结构不同你在fetch_func内部做兼容就好。4. 多线程 代理池的完整实操4.1 一个可运行的最小完整示例理论说了这么多直接上一个能跑的完整示例。这个示例模拟的场景是从某个站点批量抓取商品页面使用线程池控制并发使用代理池轮换IP带重试和失败记录。import random import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed from proxy_pool import ProxyPool class Scraper: def __init__(self, urls, max_workers8, max_retries3): self.urls urls self.max_workers max_workers self.max_retries max_retries self.session requests.Session() self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.8,en-US;q0.6,en;q0.4, }) self.proxy_pool ProxyPool(fetch_funcself.fetch_proxies) def fetch_proxies(self, count): # 这里对接你的代理供应商API # 返回格式假设为 [http://ip:port, ...] pass def fetch(self, url): for attempt in range(self.max_retries): proxy self.proxy_pool.get_proxy() if not proxy: time.sleep(1) continue proxies {http: proxy, https: proxy} try: resp self.session.get(url, proxiesproxies, timeout10) resp.raise_for_status() return url, resp except Exception as exc: self.proxy_pool.remove_proxy(proxy) if attempt self.max_retries - 1: return url, exc time.sleep(2 ** attempt) # 指数退避 def run(self): self.proxy_pool.start() with ThreadPoolExecutor(max_workersself.max_workers) as executor: future_map {executor.submit(self.fetch, url): url for url in self.urls} for future in as_completed(future_map): url future_map[future] try: url, resp future.result() if isinstance(resp, requests.Response): # 在这里做解析处理 pass except Exception as exc: print(fFailed {url}: {exc})这个代码里有几个细节值得展开说。第一个是复用了同一个requests.Session实例。Session会维护连接池TCP连接可以复用避免每次请求都重新握手的开销。第二个是代理失效的及时剔除。代理在请求抛出异常时直接被remove_proxy移出池子不会让坏代理反复被使用影响下一次请求。第三个是重试的指数退避策略。第一次失败等2秒第二次失败等4秒第三次失败等8秒。给目标服务器和代理调度留出缓冲时间避免重试时又把同一批IP打上去。4.2 参数怎么配一句话版本和最稳方案刚才示例里已经出现了max_workers、max_retries、timeout这些参数。直接给一套我常用的初始配置参数参数推荐值参考依据max_workers8~16单代理IP池规模为10左右的场景超过这个值容易触发频控timeout10秒超过该时间未响应的请求直接放弃避免线程长期被占用max_retries3超过三次重试说明问题大概率是IP或反爬层面的继续重试无意义代理池最小容量10小于这个值时需要触发补充逻辑重试退避2^attempt指数退避给服务器和代理调度留缓冲这些参数不是拍脑袋来的。就拿timeout来说设太短容易误杀慢请求设太长又会占住线程导致后续任务排队。10秒是我在多数资讯站、电商站场景下的经验值如果你抓的是境外站点或响应较慢的服务可以放宽到15~20秒。4.3 目标服务器的反向代理识别你的反爬措施够了吗讲了多线程和代理IP的配合绕不开一个问题为什么你已经用了代理IP还是会被识别和封禁因为现在的反爬早已不是简单的IP维度监测。服务器可以从浏览器指纹、TLS握手特征、HTTP头字段顺序、Cookie一致性等多个维度把真实的浏览器请求和Requests库的请求区分出来。应对思路是尽量让自己的请求看起来像一个真实用户的浏览器行为。一些能让请求更接近浏览器的技巧随机User-Agent。不要让所有请求都顶着一个固定的UA准备一个UA池每次随机选一个。请求头顺序。部分防护系统能识别HTTP头字段的顺序建议直接用浏览器复制下来的完整顺序结构而不是随意添加字段。Cookie的连续性。有些网站会在Cookie里存用户行为信息每次请求都用同一个Session能保持Cookie的连续性看起来更像一个真实的会话。请求节奏的人性化。不要每个请求间隔完全一致可以在两次请求之间加一个随机延时比如time.sleep(random.uniform(0.5, 1.5))。行为模式的随机性越高越难以被模式识别算法判定为爬虫。如果你需要应对比较严格的防护比如少数做了JS指纹检测的站点Requests这层可能就不够用了。那就得考虑playwright或者selenium这类浏览器自动化方案。不过这些方案性能开销大能不用就尽量不用。5. 常见问题与排查技巧实录5.1 高频问题和排查手段多线程 代理IP的组合遇到最多的问题我整理成了一个速查表症状可能原因排查与解决大量请求返回403/429单IP请求频率过高代理池规模不够调低max_workers扩大代理池容量观察响应头中的Retry-After字段代理IP请求超时频繁代理池中的IP质量较差或者过期没及时剔除在代理池中记录IP的失败次数连续失败2次即标记为失效并移除线程池跑完但数据丢失异常处理没做好失败的URL没有重试机制把失败URL记录到单独的待处理队列全部任务结束后统一补采抓取结果中大量返回验证页面请求指纹被识别代理IP匿名度不够升级为高匿代理完善请求头加入随机延迟多线程下内存持续增长结果堆积在线程安全队列中没有及时消费使用有界队列或由消费者线程批量写入存储后再清空实际排查的时候最有效的动作其实是打日志。很多人写爬虫不习惯打日志出问题后完全不知道请求到底走到哪一步。我的习惯是每一条请求都打一行日志包含时间、URL、使用的代理IP、HTTP状态码、耗时。等出问题时直接分析日志就能定位是网络层面的问题、代理层面的问题还是解析层面的问题。5.2 线程数和代理IP数的数学关系再深入一步。很多人在配置集群或单机多进程时对总线程数完全没有概念。这里给一个计算公式层面的参考思路总并发数 代理IP池有效数量 × 单IP最大并发数单IP最大并发数 单IP每秒允许请求数 × 单次请求平均耗时举个例子你的代理池里有50个有效IP每个IP每秒钟最多允许3次请求这是从频控规则或经验值推断的单次请求平均耗时0.6秒。那么单IP最大并发数 3 × 0.6 1.8约等于2总并发数上限 50 × 2 100但这只是理论上限。现实中还要考虑代理IP质量的波动、网络延迟的抖动、目标站点负载的压力。稳妥的做法是在这个理论值上再降个30%到50%作为安全余量。如果用了短效代理每过一两分钟IP就全部更换一批那么你的代理池调度策略还要额外考虑更换IP的空窗期。这些细节设计对长期稳定运行的采集任务来说远比一开始就从别人博客里抄一个max_workers16重要得多。5.3 个人经验代理池也要做健康检查代理池的IP不是拿来就能无限用的即使是从付费供应商拿的高匿代理也经常有某几个IP因为各种原因已经失效或变得极其缓慢。所以我在设计代理池时会额外加一个健康检查机制。具体做法是从代理池中取一个IP用一个稳定的测试URL比如百度首页或某个不会反爬的静态页面发起一次请求设置较短的超时时间5秒左右如果失败或超时就标记该IP连续失败次数加一连续失败达到一定阈值就主动从池中剔除。健康检查线程每隔一段时间跑一次确保池中数据保持有效。健康检查的频率不用太高一分钟一次足够了。频率过高反而会消耗测试URL和自己代理池的配额。这里你可以根据需要决定用哪个URL作为探针选稳定、响应快、对代理没有严格限制的页面即可。6. 一个完整应用场景动态代理爬取图片的实际案例前面聊了理论和通用代码这部分用一个我实际做过的案例把整套方案串起来。有读者在相关搜索里提到“python用动态代理ip爬取图片”这个场景确实很典型图片站点通常资源多、请求频繁而且对单个IP的访问频率非常敏感。我的做法是先用规则匹配出页面里所有的图片直链然后开一个专门的下载线程池每个线程从代理池里取IP用streamTrue模式把图片流式写入本地文件。核心代码如下import os import time import random import requests from concurrent.futures import ThreadPoolExecutor, as_completed def download_image(image_url, save_dir, proxy_pool, session): proxy proxy_pool.get_proxy() if not proxy: time.sleep(1) return False proxies {http: proxy, https: proxy} try: resp session.get(image_url, proxiesproxies, timeout15, streamTrue) resp.raise_for_status() filename os.path.join(save_dir, image_url.split(/)[-1].split(?)[0]) with open(filename, wb) as f: for chunk in resp.iter_content(chunk_size8192): f.write(chunk) return True except Exception as exc: proxy_pool.remove_proxy(proxy) print(f[failed] {image_url}: {exc}) return False finally: time.sleep(random.uniform(0.3, 0.8))图片下载和HTML抓取有一个显著区别图片文件体积大单次请求耗时长所以延迟长的IP对整体吞吐量的拖累比HTML抓取更明显。这也意味着图片下载场景对代理池质量的要求更高——宁可少一点也要保证每个IP都稳定快速。迭代下载几千张图片时我建议把已完成和未完成的图片URL记录到本地文件支持断点续传。因为一旦在批量下载过程中遇到网络抖动或代理池耗尽任务中断后从头再来的成本太高。7. 写在最后的一点个人建议多线程和代理IP的组合方案确实能让爬虫的采集效率上一个台阶但它并不是银弹。我在实际项目里反复体会到的一个道理是爬虫工程的核心不是技术炫技而是稳定和可控。技术方案再华丽遇到一个403就整体崩溃、遇到一个坏代理就导致系统挂掉那就毫无意义。真正成熟的做法是把多线程并发、代理池调度、失败重试、健康检查、日志监控这些基础设施搭建好再去谈跑多快、抓多少的问题。如果你正准备给自己当前的爬虫脚本优化我的建议是从这三点开始动手重构你的请求代码用ThreadPoolExecutor替换裸循环。接入一个代理池模块把代理IP的管理从业务代码里抽离出来。给每个请求加上日志、超时控制和重试机制。这三步做完你的爬虫就已经比市面上绝大多数教程里的示例要健壮了。后续再根据实际目标网站的特点逐步优化请求指纹、调整并发参数、完善数据存储链路整个系统的稳定性和采集效率都会显著提升。最后分享一个小技巧不管代码写得多好永远要为最坏的情况做准备。我几乎在所有爬虫项目里都会加上“失败任务持久化“的设计——把没有采集成功的URL写入本地队列文件下次启动时自动加载并续采。这个简单的设计在代理供应商突然出问题、服务器半夜重启这类意外情况发生时能帮你省下好几个小时的返工成本。 Python多线程爬虫如何搭配代理IP：从原理到实战的完整指南
我做了三年多的爬虫接过的项目从几十个页面的小脚本到千万级数据量的采集系统都有。说实话市面上讲爬虫的教程多得是但真正能把“多线程”和“代理IP”这两个东西讲透、讲明白怎么组合起来用的还真不多。前几天还有个朋友问我为什么他的爬虫程序加了ThreadPoolExecutor之后反而被封得更快了我一问才知道他为了赶进度把线程数拉到100代理IP还是从免费网站抠来的那批。这个组合不出问题才怪。这篇就从实际操作的角度把Python多线程爬虫和代理IP配套使用的完整思路、代码细节、参数调优、踩坑记录一次性聊清楚。不管你是刚入门想进阶还是已经写了几个项目但性能一直上不去这篇都值得看完。1. 慢在哪、封在哪先搞懂爬虫性能的两个瓶颈1.1 等而不是算爬虫为什么天生适合多线程很多人刚开始学爬虫的时候写的代码长这样import requests urls [https://example.com/page/1, https://example.com/page/2, ...] for url in urls: resp requests.get(url) parse(resp.text)逻辑没问题但跑起来就知道有多煎熬。几百个URL一个接一个地请求每个请求最少也要几百毫秒到一两秒的响应时间。算下来一百个页面怎么也要一两分钟。问题出在哪大部分时间都花在“等”上——等待服务器响应、等待网络传输、等待DNS解析。这个“等”的过程里CPU几乎什么都没做纯粹在睡大觉。这就是爬虫区别于普通计算任务的本质特征它是I/O密集型任务不是CPU密集型任务。计算密集型任务要靠提升CPU利用率来加速而爬虫这种场景百分之九十以上的时间都消耗在I/O等待上。既然CPU在闲着那就多开几条线程让它们在等待的同时继续发出新的请求这就是多线程带来性能提升的理论基础。用生活化的例子来说单线程爬虫就像一个人去菜市场买菜买完一根萝卜回家送回去再出门买一根白菜再送回去。多线程就像一个买手团队每个人负责一类食材大家同时出门效率自然翻了不止一倍。1.2 线程数不是越大越好GIL和其他现实约束Python有一个绕不开的话题——GIL全局解释器锁。这个锁保证同一时间只有一个线程在解释器中执行Python字节码。所以很多刚接触Python多线程的人会问既然有GIL那多线程还有意义吗答案是有没有意义取决于你的任务类型。如果是纯CPU密集型任务比如做图像处理、大规模数值计算Python多线程受GIL限制性能提升非常有限这种场景应该用多进程或者直接上asyncio配合底层C库。但对于爬虫这种I/O密集型任务请求发出后线程就阻塞在recv上此时GIL会被释放别的线程就能继续执行。换句话说多线程在爬虫里是真的能抢到并发执行效果的。但线程数也不是随便拍脑袋定的。我在实际项目里踩过一个大坑为了赶进度把线程数拉到200结果对方服务器直接返回了403最后整个IP段被封了。线程数太大一方面容易触发服务器的反向代理检测策略另一方面线程的创建、上下文切换也会消耗资源线程太多反而导致总吞吐量下降。关于线程上限的设定我需要先说明两个维度一个是安全维度。目标网站的反爬策略、单IP限流阈值、请求频率要求这些直接决定了你能跑多激进。另一个是性能维度。线程数不是越多越好因为线程调度有开销目标服务器接收能力也有限。建议从较小的值开始测试比如min(50, 目标站点的合理的并发上限)观察响应时间和错误率再缓慢往上加。一般来说单机、单IP的场景合理的线程数范围在16到64之间具体取决于目标网站的承受能力和你的代理IP池的健康程度。1.3 为什么一定要把代理IP放进方案里多线程解决的是“慢”代理IP解决的是“被限制”。很多人以为代理IP只是为了“隐藏自己的IP”这个理解太肤浅了。在真实的爬虫场景里代理IP的价值至少有三层。第一层是规避IP级别的限速和封禁。大多数网站的反爬策略都是基于IP维度的比如单个IP的每秒请求数限制、单位时间内的访问总量限制。多线程一开单IP的请求频率蹭蹭往上涨触发封禁是迟早的事。代理IP相当于给你提供了多张“通行证”把请求分散到不同IP上自然绕开了单IP的频控。第二层是数据准确性。很多网站尤其是电商、旅游类站点会根据IP归属地返回不同的内容。比如同一个商品上海IP和北京IP看到的价格可能不一样。如果你的爬虫要采集多城市的价格数据就必须用对应的地区代理IP。第三层是业务稳定性。爬虫任务往往是长期运行的比如每五分钟采集一轮价格、每小时同步一次库存。如果你只用本机IP跑一旦被识别并封禁整个数据管道就断了。代理IP池相当于给系统加了冗余单个IP挂掉不影响整体任务继续跑。2. 多线程爬虫的正确打开方式从ThreadPoolExecutor到线程安全2.1 线程池比手写线程好在哪里初学者喜欢这么写多线程import threading threads [] for url in urls: t threading.Thread(targetscrape, args(url,)) t.start() threads.append(t) for t in threads: t.join()这个写法最大的问题是线程池不受控。一次性把所有任务都创建成线程任务多的时候可能创建几百上千个线程系统资源被迅速耗尽目标服务器也会瞬间收到大量请求——基本就是在告诉对方“快来封我”。更稳的做法是使用concurrent.futures.ThreadPoolExecutor。线程池会维护固定数量的工作线程把任务放进内部队列Worker不断从队列里取任务执行。这样做的好处有三个线程数量可控可以通过max_workers参数精确控制并发度。任务提交方便用submit方法提交单个任务也可以直接用map批量提交。获取结果简单future.result()可以直接拿返回值不需要手动管理线程间的通信。一个标准的线程池爬虫核心逻辑长这样from concurrent.futures import ThreadPoolExecutor, as_completed def fetch_url(url): try: resp requests.get(url, timeout10) resp.raise_for_status() return url, resp.text except Exception as exc: return url, exc with ThreadPoolExecutor(max_workers16) as executor: future_map {executor.submit(fetch_url, url): url for url in urls} for future in as_completed(future_map): url future_map[future] try: url, result future.result() except Exception as exc: print(f{url} generated an exception: {exc})注意我用了一个future_map来保存URL和Future对象的映射关系。这样在as_completed遍历结果时可以精准定位到具体是哪个URL执行完了方便做日志记录和失败重试。2.2 线程安全与数据共享别让变量到处乱飞多线程的另一个经典陷阱是共享变量冲突。想象这个场景你有一个全局计数器用来统计成功抓取了多少个页面主线程每隔几秒打印一次进度。你开心地写着global_count 0 def worker(url): global global_count resp requests.get(url) parse(resp.text) global_count 1这个global_count 1在多线程环境下就是典型的竞态条件。虽然Python的GIL在一定程度上减少了纯Python操作发生数据竞争的概率但这个操作实际上包含“读取、计算、写回”三个步骤线程可能在任何一步被切走导致计数丢失。解决方式有两个层面。第一个层面如果是简单的计数器直接用threading.Lock包一下import threading lock threading.Lock() global_count 0 def worker(url): global global_count resp requests.get(url) parse(resp.text) with lock: global_count 1第二个层面如果数据结构更复杂比如多个线程需要向同一个列表或字典写入结果推荐用queue.Queue作为数据中转站。Queue内部实现了线程安全机制自带锁不需要你自己再加。Worker线程把结果放进队列主线程或单独的写入线程从队列里取数据再批量化写入文件或数据库。这样既解耦了生产者和消费者又避免了锁的滥用。2.3 多线程爬虫的性能调优找到你的黄金并发值很多读者会问max_workers到底设置多少合适这个问题没有标准答案但有一套可行的推断方法。核心指标是单个IP的请求间隔和单次请求的平均耗时。假设目标网站允许单个IP每秒最多请求N次你的单个请求平均耗时是T秒。那么单IP的理论最大并发值约为N * T。举个例子如果目标网的频控大约是每秒5次而你的单次请求平均耗时0.5秒那么并发值可以定在5 * 0.5 3左右。这个数值保证在任何一秒内发出的请求不会超过频控限制。但如果你同时使用了代理IP池有多个代理IP在帮你分流那并发值就可以乘以代理IP的数量。这也是为什么代理IP和多线程是一对黄金搭档——代理IP池越大多线程的并行上限就越高。实际操作时我一般建议这样起步先用max_workers1跑一分钟记录单次请求的平均耗时和失败率。逐渐调高到4、8、16每档跑一两分钟观察总吞吐量和HTTP错误率的变化。当错误率开始明显上升说明频控或防护开始生效。这时的并发数再打一个七到八折就是当前代理池配置下的安全并发值。3. 代理IP池设计与选型IP是越贵越好吗3.1 代理类型对比该用透明、匿名还是高匿代理代理IP之间也有很大区别主要按照匿名程度分成三类。透明代理服务器能检测到你在使用代理并且能看到你的真实IP。这种代理在爬虫场景基本没有防护能力只能用来访问一些完全不设防的站点。普通匿名代理服务器能检测到代理的存在但看不到你的真实IP。这类代理适合一些轻度反爬的网站但对某些严格的指纹检测还是会被识别。高匿名代理服务器既检测不到代理的使用痕迹也看不到真实IP。在目标服务器的视角里请求就像来自一个普通用户的真实网络环境。大部分严肃采集场景都需要高匿代理。除了匿名等级代理IP还有两种使用模式。一种是短效动态代理每次请求或每几分钟更换一个新IP。适合大规模采集、对IP时效性要求高的场景电商价格监控、舆情监测、批量抓数据这类任务用得最多。另一种是隧道代理你只需要对接一个固定地址代理服务商在后台自动帮你轮换IP。客户端不需要自己管理IP列表代码更简洁稳定性更好但单价也更高。我个人的建议如果只是学习、调试用隧道代理最省心。如果是生产环境且技术能力允许短效动态代理配合本地代理池灵活性和成本控制都更好。好的接下来我把代理IP和代码结合的具体方案展开说。3.2 自建代理池还是买现成的API这里要看你的预算和人力。自建代理池的完整链路是爬取免费代理 - 校验可用性 - 存储 - 调度分配。看上去很酷但免费代理的可用率通常只有百分之几到百分之十几而且稳定性极差采集过程中随时可能IP失效。爬虫代码还没写多少代理池的维护代码已经一大堆了。买现成的代理API则简单得多。一般代理服务商都提供API接口你只需要从接口拿IP塞给requests的proxies参数即可。国内比较成熟的服务商都能做到秒级切换IP、全国地区定向、按量计费。唯一的缺点是花钱但相比自建代理池所投入的时间和服务器成本通常还是划算的。如果你打算走API这条路我建议留意代理IP的存活时间是多长。短效代理是按次计费还是按时间计费对代码设计影响很大。是否支持指定地区。多城市数据采集必须支持。接口返回的IP是否已经去重以及生效时间是即时还是需要等待一段时间。是否支持批量提取。一次提取多个IP能减少API调用次数降低被限流的风险。这里需要说明一下不同服务商的产品规则差异很大具体接入方式要以你选用的服务商文档为准。下面给出的逻辑是一套通用的轮换方案设计思路核心思想是“缓冲对列 定期刷新 失败剔除”。3.3 让代码自己管理代理一个轻量级代理池实现我自己写爬虫时从来不直接在生产代码里硬编码代理IP。原因很简单代理IP有生命周期短效代理可能几分钟就失效了写死了就意味着频繁改代码。我的做法是在项目里维护一个轻量的代理池模块。核心思想是一个线程负责定期从API拉取新IP另一个负责从队列里取IP供爬虫使用爬虫用完归还如果IP失效则直接丢弃。import queue import threading import time import requests class ProxyPool: def __init__(self, fetch_func, min_size10, max_size50): self._pool queue.Queue(maxsizemax_size) self._fetch_func fetch_func self._min_size min_size self._lock threading.Lock() def start(self): threading.Thread(targetself._refill_loop, daemonTrue).start() def _refill_loop(self): while True: with self._lock: if self._pool.qsize() self._min_size: new_proxies self._fetch_func(self._min_size - self._pool.qsize()) for proxy in new_proxies: try: self._pool.put_nowait(proxy) except queue.Full: break time.sleep(5) def get_proxy(self): try: return self._pool.get(timeout3) except queue.Empty: return None def remove_proxy(self, proxy): with self._lock: try: # 重新填充弥补失效代理造成的空缺 self._pool.task_done() except ValueError: pass这个实现的好处是爬虫主逻辑不需要关心代理从哪来、什么时候过期只需要get_proxy拿IP失效了就remove_proxy通知池子补充新IP。整体耦合度很低。我个人的做法是把获取新IP的操作封装成一个fetch_func这样既可以接付费代理API也可以接自建的免费代理采集脚本。想换供应商的时候只需要改几行代码。建议你根据自己的情况灵活调整如果市面API的返回结构不同你在fetch_func内部做兼容就好。4. 多线程 代理池的完整实操4.1 一个可运行的最小完整示例理论说了这么多直接上一个能跑的完整示例。这个示例模拟的场景是从某个站点批量抓取商品页面使用线程池控制并发使用代理池轮换IP带重试和失败记录。import random import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed from proxy_pool import ProxyPool class Scraper: def __init__(self, urls, max_workers8, max_retries3): self.urls urls self.max_workers max_workers self.max_retries max_retries self.session requests.Session() self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.8,en-US;q0.6,en;q0.4, }) self.proxy_pool ProxyPool(fetch_funcself.fetch_proxies) def fetch_proxies(self, count): # 这里对接你的代理供应商API # 返回格式假设为 [http://ip:port, ...] pass def fetch(self, url): for attempt in range(self.max_retries): proxy self.proxy_pool.get_proxy() if not proxy: time.sleep(1) continue proxies {http: proxy, https: proxy} try: resp self.session.get(url, proxiesproxies, timeout10) resp.raise_for_status() return url, resp except Exception as exc: self.proxy_pool.remove_proxy(proxy) if attempt self.max_retries - 1: return url, exc time.sleep(2 ** attempt) # 指数退避 def run(self): self.proxy_pool.start() with ThreadPoolExecutor(max_workersself.max_workers) as executor: future_map {executor.submit(self.fetch, url): url for url in self.urls} for future in as_completed(future_map): url future_map[future] try: url, resp future.result() if isinstance(resp, requests.Response): # 在这里做解析处理 pass except Exception as exc: print(fFailed {url}: {exc})这个代码里有几个细节值得展开说。第一个是复用了同一个requests.Session实例。Session会维护连接池TCP连接可以复用避免每次请求都重新握手的开销。第二个是代理失效的及时剔除。代理在请求抛出异常时直接被remove_proxy移出池子不会让坏代理反复被使用影响下一次请求。第三个是重试的指数退避策略。第一次失败等2秒第二次失败等4秒第三次失败等8秒。给目标服务器和代理调度留出缓冲时间避免重试时又把同一批IP打上去。4.2 参数怎么配一句话版本和最稳方案刚才示例里已经出现了max_workers、max_retries、timeout这些参数。直接给一套我常用的初始配置参数参数推荐值参考依据max_workers8~16单代理IP池规模为10左右的场景超过这个值容易触发频控timeout10秒超过该时间未响应的请求直接放弃避免线程长期被占用max_retries3超过三次重试说明问题大概率是IP或反爬层面的继续重试无意义代理池最小容量10小于这个值时需要触发补充逻辑重试退避2^attempt指数退避给服务器和代理调度留缓冲这些参数不是拍脑袋来的。就拿timeout来说设太短容易误杀慢请求设太长又会占住线程导致后续任务排队。10秒是我在多数资讯站、电商站场景下的经验值如果你抓的是境外站点或响应较慢的服务可以放宽到15~20秒。4.3 目标服务器的反向代理识别你的反爬措施够了吗讲了多线程和代理IP的配合绕不开一个问题为什么你已经用了代理IP还是会被识别和封禁因为现在的反爬早已不是简单的IP维度监测。服务器可以从浏览器指纹、TLS握手特征、HTTP头字段顺序、Cookie一致性等多个维度把真实的浏览器请求和Requests库的请求区分出来。应对思路是尽量让自己的请求看起来像一个真实用户的浏览器行为。一些能让请求更接近浏览器的技巧随机User-Agent。不要让所有请求都顶着一个固定的UA准备一个UA池每次随机选一个。请求头顺序。部分防护系统能识别HTTP头字段的顺序建议直接用浏览器复制下来的完整顺序结构而不是随意添加字段。Cookie的连续性。有些网站会在Cookie里存用户行为信息每次请求都用同一个Session能保持Cookie的连续性看起来更像一个真实的会话。请求节奏的人性化。不要每个请求间隔完全一致可以在两次请求之间加一个随机延时比如time.sleep(random.uniform(0.5, 1.5))。行为模式的随机性越高越难以被模式识别算法判定为爬虫。如果你需要应对比较严格的防护比如少数做了JS指纹检测的站点Requests这层可能就不够用了。那就得考虑playwright或者selenium这类浏览器自动化方案。不过这些方案性能开销大能不用就尽量不用。5. 常见问题与排查技巧实录5.1 高频问题和排查手段多线程 代理IP的组合遇到最多的问题我整理成了一个速查表症状可能原因排查与解决大量请求返回403/429单IP请求频率过高代理池规模不够调低max_workers扩大代理池容量观察响应头中的Retry-After字段代理IP请求超时频繁代理池中的IP质量较差或者过期没及时剔除在代理池中记录IP的失败次数连续失败2次即标记为失效并移除线程池跑完但数据丢失异常处理没做好失败的URL没有重试机制把失败URL记录到单独的待处理队列全部任务结束后统一补采抓取结果中大量返回验证页面请求指纹被识别代理IP匿名度不够升级为高匿代理完善请求头加入随机延迟多线程下内存持续增长结果堆积在线程安全队列中没有及时消费使用有界队列或由消费者线程批量写入存储后再清空实际排查的时候最有效的动作其实是打日志。很多人写爬虫不习惯打日志出问题后完全不知道请求到底走到哪一步。我的习惯是每一条请求都打一行日志包含时间、URL、使用的代理IP、HTTP状态码、耗时。等出问题时直接分析日志就能定位是网络层面的问题、代理层面的问题还是解析层面的问题。5.2 线程数和代理IP数的数学关系再深入一步。很多人在配置集群或单机多进程时对总线程数完全没有概念。这里给一个计算公式层面的参考思路总并发数 代理IP池有效数量 × 单IP最大并发数单IP最大并发数 单IP每秒允许请求数 × 单次请求平均耗时举个例子你的代理池里有50个有效IP每个IP每秒钟最多允许3次请求这是从频控规则或经验值推断的单次请求平均耗时0.6秒。那么单IP最大并发数 3 × 0.6 1.8约等于2总并发数上限 50 × 2 100但这只是理论上限。现实中还要考虑代理IP质量的波动、网络延迟的抖动、目标站点负载的压力。稳妥的做法是在这个理论值上再降个30%到50%作为安全余量。如果用了短效代理每过一两分钟IP就全部更换一批那么你的代理池调度策略还要额外考虑更换IP的空窗期。这些细节设计对长期稳定运行的采集任务来说远比一开始就从别人博客里抄一个max_workers16重要得多。5.3 个人经验代理池也要做健康检查代理池的IP不是拿来就能无限用的即使是从付费供应商拿的高匿代理也经常有某几个IP因为各种原因已经失效或变得极其缓慢。所以我在设计代理池时会额外加一个健康检查机制。具体做法是从代理池中取一个IP用一个稳定的测试URL比如百度首页或某个不会反爬的静态页面发起一次请求设置较短的超时时间5秒左右如果失败或超时就标记该IP连续失败次数加一连续失败达到一定阈值就主动从池中剔除。健康检查线程每隔一段时间跑一次确保池中数据保持有效。健康检查的频率不用太高一分钟一次足够了。频率过高反而会消耗测试URL和自己代理池的配额。这里你可以根据需要决定用哪个URL作为探针选稳定、响应快、对代理没有严格限制的页面即可。6. 一个完整应用场景动态代理爬取图片的实际案例前面聊了理论和通用代码这部分用一个我实际做过的案例把整套方案串起来。有读者在相关搜索里提到“python用动态代理ip爬取图片”这个场景确实很典型图片站点通常资源多、请求频繁而且对单个IP的访问频率非常敏感。我的做法是先用规则匹配出页面里所有的图片直链然后开一个专门的下载线程池每个线程从代理池里取IP用streamTrue模式把图片流式写入本地文件。核心代码如下import os import time import random import requests from concurrent.futures import ThreadPoolExecutor, as_completed def download_image(image_url, save_dir, proxy_pool, session): proxy proxy_pool.get_proxy() if not proxy: time.sleep(1) return False proxies {http: proxy, https: proxy} try: resp session.get(image_url, proxiesproxies, timeout15, streamTrue) resp.raise_for_status() filename os.path.join(save_dir, image_url.split(/)[-1].split(?)[0]) with open(filename, wb) as f: for chunk in resp.iter_content(chunk_size8192): f.write(chunk) return True except Exception as exc: proxy_pool.remove_proxy(proxy) print(f[failed] {image_url}: {exc}) return False finally: time.sleep(random.uniform(0.3, 0.8))图片下载和HTML抓取有一个显著区别图片文件体积大单次请求耗时长所以延迟长的IP对整体吞吐量的拖累比HTML抓取更明显。这也意味着图片下载场景对代理池质量的要求更高——宁可少一点也要保证每个IP都稳定快速。迭代下载几千张图片时我建议把已完成和未完成的图片URL记录到本地文件支持断点续传。因为一旦在批量下载过程中遇到网络抖动或代理池耗尽任务中断后从头再来的成本太高。7. 写在最后的一点个人建议多线程和代理IP的组合方案确实能让爬虫的采集效率上一个台阶但它并不是银弹。我在实际项目里反复体会到的一个道理是爬虫工程的核心不是技术炫技而是稳定和可控。技术方案再华丽遇到一个403就整体崩溃、遇到一个坏代理就导致系统挂掉那就毫无意义。真正成熟的做法是把多线程并发、代理池调度、失败重试、健康检查、日志监控这些基础设施搭建好再去谈跑多快、抓多少的问题。如果你正准备给自己当前的爬虫脚本优化我的建议是从这三点开始动手重构你的请求代码用ThreadPoolExecutor替换裸循环。接入一个代理池模块把代理IP的管理从业务代码里抽离出来。给每个请求加上日志、超时控制和重试机制。这三步做完你的爬虫就已经比市面上绝大多数教程里的示例要健壮了。后续再根据实际目标网站的特点逐步优化请求指纹、调整并发参数、完善数据存储链路整个系统的稳定性和采集效率都会显著提升。最后分享一个小技巧不管代码写得多好永远要为最坏的情况做准备。我几乎在所有爬虫项目里都会加上“失败任务持久化“的设计——把没有采集成功的URL写入本地队列文件下次启动时自动加载并续采。这个简单的设计在代理供应商突然出问题、服务器半夜重启这类意外情况发生时能帮你省下好几个小时的返工成本。