异步爬虫性能优于多线程，因asyncio事件循环在用户态切换协程，开销纳秒级，无gil和os调度瓶颈；aiohttp不可混用requests，否则阻塞事件循环；需配置连接池、dns缓存与超时。
因为异步爬虫在纯网络 I/O 场景下，没有线程切换开销、内存占用极低、单线程就能支撑上万并发连接——而多线程受限于 GIL 和 OS 调度，在几百线程后就开始边际递减甚至反向拖慢。
asyncio 事件循环如何避免线程切换开销
多线程靠操作系统调度线程时间片，每次切换都要保存/恢复寄存器、栈、上下文，尤其当线程数超过 CPU 核心数（比如开 100 个线程），OS 调度本身就成了瓶颈。而 asyncio 的事件循环完全在用户态运行，await 时只是把控制权交还给 loop，协程状态存在内存里，切换成本是纳秒级的。
常见错误现象：ThreadPoolExecutor(max_workers=100) 在爬取 1000 个 URL 时，实际并发可能卡在 30–50 之间，且 CPU 使用率飙升但吞吐没涨——这不是代码写错了，是 OS 已经忙于调度而非干活。
- 协程切换不触发 GIL 争抢，也不依赖内核调度器
- 一个
asyncio.run()进程里轻松启动 5000+aiohttp.ClientSession请求任务 - 实测中，100 协程耗时约 6 秒；20 线程耗时约 18 秒（同环境爬 1000 个静态页）
aiohttp 为什么不能和 requests 混用
aiohttp 是异步 HTTP 客户端，所有 I/O 操作（如 session.get()）都返回 Awaitable 对象；而 requests 是同步阻塞库，一旦调用就会卡死当前协程，整个事件循环停摆。
使用场景：你在 async def 函数里写了 requests.get(...)，程序不会报错，但表现和单线程一样——因为那个协程被阻塞了，loop 无法调度其他任务。
- 错误示例：
async def fetch(): return requests.get("https://example.com")—— 这不是异步，是“假装异步” - 必须全程用异步栈：aiohttp + asyncio + async/await，不能中间插 requests 或 time.sleep()
- 若必须调用同步函数（如某解析库无异步版），得用
loop.run_in_executor()托管到线程池，但会引入额外开销
高并发下连接池与 DNS 缓存的实际影响
很多人以为“开更多协程 = 更快”，但真实瓶颈常出现在客户端连接管理上。默认 aiohttp.TCPConnector 限制总连接数为 100，如果并发 5000 协程，大量请求会在 connector 队列里排队等待空闲连接，反而拉长平均延迟。
性能 / 兼容性影响：DNS 解析默认也是同步阻塞的，高频请求下可能成为隐形瓶颈。不显式配置，aiohttp 会反复调用系统 getaddrinfo，而它不走 event loop。
- 必须手动配置连接池：
TCPConnector(limit=300, limit_per_host=30) - DNS 缓存需启用：
resolver=aiohttp.AsyncResolver()，否则每请求都重查 DNS - 超时必须设全：
timeout=aiohttp.ClientTimeout(total=10, connect=5)，否则一个卡死请求会拖垮整批协程
真正拉开差距的不是语法，而是对「等待」的抽象方式：多线程把等待交给 OS，异步把等待变成可调度的暂停点。一旦你开始调大并发数，这个底层差异就会指数级放大——而多数人只在 max_workers=10 时测试，根本压不出问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
