Python如何提高爬虫抓取效率_基于asyncio与aiohttp并发机制

Python异步爬虫：从“能用”到“高效”的关键配置

用上 aiohttp 和 asyncio，实现单机并发上百个请求听起来很美，但实际跑起来，吞吐量常常不尽如人意。问题出在哪？很多时候，瓶颈并不在并发数本身，而在于一些隐蔽的配置细节和生命周期管理上。加了 async 关键字并不等于自动提速，真正的性能提升，来自于对以下环节的精细控制。

为什么 asyncio.run() 启动后反而比 requests 慢？

一个典型的场景是：明明发了50个异步请求，总耗时却比同步的 requests 还要长。这背后的根本原因，往往是 aiohttp.ClientSession 没有被正确复用。

很多初学者会习惯性地在每个抓取函数里都写一句 async with aiohttp.ClientSession() as session:。殊不知，每一次 async with 都会新建一个完整的TCP连接池、SSL上下文以及DNS缓存。这相当于每次请求都重新“握手”一次，开销巨大。

• 共享会话是关键：必须将 ClientSession 提升到最外层，作为所有协程共享的全局上下文，而不是临时创建。
• DNS缓存的取舍：禁用默认的DNS缓存（connector = aiohttp.TCPConnector(use_dns_cache=False)）在某些情况下反而能提速。尤其是当目标域名众多且比较冷门时，内置的缓存机制可能会阻塞协程，等待解析完成。
• 控制单主机连接数：将 limit_per_host 设置为一个合理的值（例如30，而非默认的100），可以有效避免对单个域名触发服务端的连接限流或拒绝。

必须复用 ClientSession 并配置 TCPConnector：禁用 DNS 缓存、设 limit_per_host=30；响应体优先 read() 后显式解码，大文件流式处理；避免 gather 列表推导式，改用 create_task 动态调度。

如何避免 await response.text() 成为性能瓶颈？

另一个常见的性能陷阱藏在响应体处理里。response.text() 方法虽然方便，但它默认会使用 chardet 库自动探测编码，这个过程CPU占用高且不可控。相比之下，response.read() 直接返回 bytes 的速度要快得多，只是后续需要手动处理解码。

• 优先读取字节流：使用 await response.read() 获取原始字节数据，然后根据 response.charset 或响应头 content-type 中指定的 charset 进行显式解码。
• 跳过编码探测：如果能够确定目标页面编码是 UTF-8，直接使用 (await response.read()).decode('utf-8')，可以完全跳过耗时的自动探测过程。
• 流式处理大文件：对于超过1MB的大响应体，切忌一次性 .read() 到内存。应该改用 content = response.content，然后通过 async for chunk in content.iter_chunked(8192): 进行流式处理，这对内存友好，也能提升整体吞吐。

asyncio.gather() 和 asyncio.create_task() 的选择陷阱

并发任务的组织方式直接影响着程序的稳健性和资源消耗。下面这种写法看似并发，实则暗藏问题：

await asyncio.gather(*[fetch(session, url) for url in urls])

问题在于，列表推导式会一次性生成所有的协程对象，如果URL列表很大，内存占用会瞬间飙升。而且，这种写法缺乏灵活性，无法对其中部分任务进行中途取消或精细的超时控制。

立即学习“Python免费学习笔记（深入）”；

• 小批量任务：对于数量可控的任务，asyncio.gather() 依然简洁高效，但务必加上 return_exceptions=True 参数。否则，任何一个任务抛出异常都会导致整个 gather 失败，其他成功的结果也无法获取。
• 大批量或需容错：更推荐使用 asyncio.create_task() 批量提交任务，然后配合 asyncio.as_completed() 按完成顺序处理结果。这种方式允许你随时对某个任务调用 task.cancel()，控制粒度更细。
• 绝对要避免的写法：永远不要在循环里直接写 await fetch(...)。这相当于把异步操作又变回了串行，完全失去了并发意义。

超时与重试必须手动精细控制

aiohttp 客户端自带的 timeout 参数，其控制范围仅限于建立连接和读取响应头。对于后续的 response.text() 或大响应体的下载耗时，它是管不到的——这部分超时必须自己动手，用 asyncio.wait_for() 来包裹。

• 连接与读取超时：使用 aiohttp.ClientTimeout(total=10, connect=3, sock_read=5) 来分别控制总超时、连接超时和读取首字节超时。
• 全文本解析超时：对于耗时的解码或处理过程，使用 await asyncio.wait_for(response.text(), timeout=8) 来单独设定超时。
• 手写重试逻辑：对于重试机制，依赖第三方库有时反而增加复杂度。一个简单可控的三段式手写逻辑往往更可靠：for attempt in range(3): try: ... break except aiohttp.ClientError: continue。
• 重试时的连接注意：重试时，不要简单地重复使用失败的 session.request() 调用。因为失败的连接可能处于半关闭状态。更安全的做法是，在重试循环内新建一个 request 调用。

说到底，真正卡住异步爬虫效率的，往往不是并发数不够高，而是DNS解析策略、连接复用粒度、响应体处理方式这些“细枝末节”。它们通常不会导致程序报错，但却能悄无声息地让异步并发的优势荡然无存。把这些细节配置到位，才是从“能用”到“高效”的必经之路。