应改用 aiohttp + asyncio 替代 requests.get() 串行请求，因其在io密集场景下性能高3倍以上、资源占用更低，但需合理配置连接池、超时及并发数，并避免漏写 await、混入阻塞操作、忽略异常等常见错误。

直接换 aiohttp + asyncio，别再用 requests.get() 串行发请求了。单线程协程在 IO 密集场景下，性能常比多线程高 3 倍以上，且内存和 CPU 占用更低——前提是连接池配对、错误不炸穿、并发数不瞎设。

为什么 requests + time.sleep 一跑就卡死

每次调用 requests.get() 都新建 TCP 连接，三次握手 + SSL 握手耗时动辄 200–500ms；time.sleep(1) 更是让整个线程停摆，100 个 URL 就得等 100 秒。这不是爬虫，是排队打卡。

关键问题不在“慢”，而在“阻塞”：一个请求没回，别的全干等。真实网络环境里，90% 时间花在等响应上，CPU 却闲着。

• requests 默认不复用连接，除非你显式传 Session 并启用 pool_connections
• time.sleep() 是同步阻塞，协程里绝对不能用，会挂起整个事件循环
• 没设超时的 requests.get() 可能卡住几十秒，而 aiohttp 必须显式指定 timeout

aiohttp.ClientSession 的连接池必须手动配

aiohttp 的并发能力不是开箱即用的。默认 ClientSession 的连接池极小（通常只有 10–20 个空闲连接），并发数一超就排队等连接，反而比串行还慢。

实操建议：

Forge — Python Developer

Python开发助手 — 自动化脚本、API封装、命令行工具、数据管道、网页爬虫。经过测试的代码，包含错误处理和文档。当你需要...

下载

• 初始化 ClientSession 时务必设置 connector，例如：aiohttp.TCPConnector(limit=100, limit_per_host=30)
• limit 控制全局最大连接数，limit_per_host 防止单域名打爆（避免被封）
• 记得加 timeout：用 aiohttp.ClientTimeout(total=10)，别依赖默认值
• 不要在循环里反复创建 ClientSession，它本就是为复用设计的

async/await 写法里最容易崩的三个点

协程代码看着像同步，但执行逻辑完全不同。以下错误会导致任务静默失败、内存暴涨或 event loop 崩溃：

• 漏写 await：比如调用 fetch(session, url) 却没加 await，返回的是 coroutine 对象而非结果，asyncio.gather() 会直接报 TypeError: an integer is required
• 把阻塞函数塞进协程：比如在 fetch() 里调用 time.sleep() 或 json.loads() 大文本，会卡住整个 loop；大解析任务建议用 loop.run_in_executor() 拆出去
• 异常没捕获：一个请求 404 或超时未 try/except，整个 gather() 就中断；推荐用 return_exceptions=True 让失败不中断其他任务

并发数不是越大越好，得看目标站扛不扛得住

本地压测 100 并发可能跑得飞快，但真实场景中，目标网站的反爬策略、CDN 限速、后端 QPS 限制才是瓶颈。盲目提高并发，换来的是 429、503、IP 封禁。

稳妥做法：

• 先从 10–20 并发起步，观察平均响应时间与成功率
• 用 aiohttp 的 raise_for_status() 主动抛异常，配合重试（如 tenacity 库）比硬扛更稳
• 如果发现大量 ClientConnectorError 或 ServerDisconnectedError，说明连接池或目标服务已到极限，该降并发或加延迟
• 别忘了 User-Agent 和 Referer —— 没这些，有些站连 DNS 解析都给你缓存成 403

真正卡住人的从来不是语法，而是连接池参数没调、异常没兜底、并发数拍脑袋定。这三处不动，换再 fancy 的框架也白搭。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！