应优先选用 asyncio + httpx 协程方案，因其连接池自动适配协程调度、无锁开销、吞吐高；若含大量同步阻塞或 cpu 密集操作，则选多线程并需为每个线程配置独立 session 和线程安全连接池。
requests + threading 为什么经常卡死或报错
直接用 requests 配合 threading.Thread 发并发请求，大概率会遇到连接池耗尽、Max retries exceeded 或 ConnectionResetError。根本原因是 requests 底层的 urllib3.PoolManager 默认只维护有限连接（通常 10 个），多线程争抢同一连接池，又没做线程安全配置。
实操建议：
- 必须显式创建带足够
maxsize和线程安全配置的PoolManager，并绑定到每个Session - 每个线程应持有独立的
requests.Session()实例，避免共享状态 - 加
threading.Semaphore控制并发数，别盲目开几百个线程
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
def make_session():
session = requests.Session()
retry = Retry(total=2, backoff_factor=0.3)
adapter = HTTPAdapter(
pool_connections=50,
pool_maxsize=50,
max_retries=retry
)
session.mount("http://", adapter)
session.mount("https://", adapter)
return session
asyncio + httpx 是目前最稳的协程方案
httpx.AsyncClient 原生支持 asyncio，连接池自动适配协程调度，没有线程锁开销，内存占用低，吞吐高。相比 aiohttp，httpx API 更接近 requests，迁移成本小，还支持 HTTP/2 和同步/异步混用。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 忘记
await client.get(...)，直接调用返回 coroutine 对象，后续报TypeError: object is not async - 在非 async 函数里调用
asyncio.run()多次，导致 event loop 已关闭 - 没限制并发数，
asyncio.gather(*tasks)一次性扔几千个请求，触发服务端限流或本地文件描述符耗尽
import asyncio
import httpx
async def fetch(client, url):
try:
r = await client.get(url, timeout=5.0)
return r.status_code, r.text[:100]
except Exception as e:
return -1, str(e)
async def main():
async with httpx.AsyncClient() as client:
tasks = [fetch(client, "https://httpbin.org/delay/1") for _ in range(50)]
results = await asyncio.gather(*tasks, return_exceptions=True)
return results
什么时候该选多线程，而不是协程
不是所有 IO 场景都适合协程。当你的“请求逻辑”里混杂了大量同步阻塞操作（比如本地文件解析、CPU 密集型处理、调用不支持 async 的第三方库），强行塞进 async def 反而降低性能，甚至引发死锁。
适用多线程的真实场景：
- 接口响应快（
- 调用的是封装在 .so/.dll 里的闭源 SDK，它内部是阻塞式网络+计算
- 已有成熟线程安全的缓存模块（如
threading.local+ redis 连接），改造成 async 成本过高
此时用 concurrent.futures.ThreadPoolExecutor + loop.run_in_executor 混合调度更实际。
超时、重试、限流必须按层配置
并发下，单点超时不等于全局可控。网络超时、连接超时、读取超时、重试策略、客户端限流、服务端限流，这五层必须分开看、分别设。
关键参数对照：
-
requests：用timeout=(connect_timeout, read_timeout)，别只写一个数字 -
httpx：timeout=httpx.Timeout(5.0, connect=3.0, read=5.0)，支持细粒度控制 - 重试：
urllib3.Retry或httpx.Limit配合AsyncClient的event_hooks - 客户端限流：用
asyncio.Semaphore(n)包裹请求逻辑，比靠服务端 429 更可靠
最容易被忽略的是 DNS 解析超时 —— 它不包含在 connect 超时里，httpx 需额外设 httpx.Limits 的 max_keepalive_connections，requests 则依赖系统 resolver 行为。
