用asyncio.gather()+aiohttp.ClientSession最稳妥，但须配ClientTimeout、TCPConnector和asyncio.Semaphore三重防护，否则易致端口耗尽、DNS阻塞或服务拒绝。
直接上结论：用 asyncio.gather() + aiohttp.ClientSession 是当前最稳妥的组合，但并发数不能无脑设高，否则多数请求会卡在 DNS 或连接超时，实际吞吐反而暴跌。
为什么不用 requests 配 asyncio.to_thread？
requests 是同步阻塞库，即使丢进 to_thread，也只是把单个请求扔到线程池里跑——它不释放事件循环，无法真正并发；更关键的是，线程池有默认上限（通常 64），海量 URL 下排队严重，且内存开销翻倍。而 aiohttp 原生支持异步 HTTP，复用 TCP 连接、自动管理 DNS 缓存，才是 asyncio 生态里的正确搭档。
- 别碰
urllib.request+asyncio组合，它没异步接口，硬套只会出RuntimeError: This event loop is already running -
aiohttp的timeout必须显式设置，否则默认永不超时，一个挂掉的域名会让整个任务卡死 - 如果目标网站有反爬，
aiohttp不自带 User-Agent 轮换，得自己加中间件或随机头
如何控制并发量不炸 DNS 和被封 IP？
并发数不是越大越好。实测发现，超过 100 之后，aiohttp 的 DNS 解析开始排队，大量请求卡在 Unclosed connector 或 TimeoutError: [Errno 110] Connection timed out。合理做法是用 asyncio.Semaphore 限流，并配合连接池参数收紧。
- 设
semaphore = asyncio.Semaphore(50)，所有请求前await semaphore.acquire()，结束后semaphore.release() - 初始化
ClientSession时传connector=aiohttp.TCPConnector(limit=50, limit_per_host=5)：前者控总连接数，后者防单域名压垮 - DNS 缓存建议开启：
TCPConnector(use_dns_cache=True, ttl_dns_cache=300)，避免重复查同一域名
遇到 ClientOSError: [Errno 24] Too many open files 怎么办？
这是系统级文件描述符耗尽，不是 Python 错误。Linux 默认每个进程最多打开 1024 个文件（含 socket），而每个 aiohttp 连接占至少 1 个。解决路径很明确：调高限制 + 减少连接占用。
立即学习“Python免费学习笔记（深入）”；
- 临时提限：
ulimit -n 65536（仅当前 shell 有效） - 永久提限：修改
/etc/security/limits.conf，加两行* soft nofile 65536和* hard nofile 65536 - 代码里必须
await session.close()，且推荐用async with ClientSession(...) as session:确保释放 - 避免为每个请求新建
ClientSession，复用一个实例，否则连接池失效，文件句柄暴增
真正难调的不是语法，是平衡：DNS 响应时间、目标站 TCP backlog、本地网络栈缓冲区、操作系统 fd 限制——这些全堆在 aiohttp 底层，暴露给你的只有超时和连接池参数。调参前先用 curl -w "@format.txt" -o /dev/null -s http://example.com 测下真实延迟，比拍脑袋设 100 并发靠谱得多。
