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)）反而能提升速度。特别是当爬虫需要访问大量不同且冷门的域名时，内置的缓存机制可能导致协程阻塞，等待DNS解析完成。
• 合理限制单主机连接数：将 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() 直接返回字节数据的速度要快得多，只是后续需要手动进行解码操作。

• 优先获取字节数据：使用 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解析策略、连接复用粒度、响应体处理方式这些容易被忽略的“细节”。它们通常不会导致程序直接崩溃，却能悄无声息地吞噬掉异步并发带来的性能优势。将这些关键配置调整到位，才是实现Python异步爬虫从“功能可用”迈向“高效稳定”的必经之路。