requests vs httpx vs aiohttp：到底选哪个

上周帮人 code review，代码里同时 import 了三个 HTTP 库。

问他为什么，他说：“我看别人项目里都有，就全加上了。”

有点无语，但很理解——这三个库确实容易让人迷糊。requests 用了好多年，httpx 冒出来说自己是“现代版 requests”，aiohttp 又跳出来说“我更快”，结果就是很多人稀里糊涂全装上了。

今天把这三个库掰开了说清楚，讲讲我自己的选法。

先给结论

不想看长文的，直接看这四个判断：

• 写脚本、爬虫、简单接口调用 → requests
• 新项目，需要同时支持 sync/async → httpx
• 高并发异步项目（asyncio 主场）→ aiohttp
• 生产环境高性能 API 调用 → httpx 异步模式 或 aiohttp

如果你现在用 requests 跑得好好的，没有性能问题——别动。继续往下看只是想了解一下。

requests：这个老家伙凭什么是行业标准

requests 的地位不用多说。2011 年发布，Star 数 50k+，几乎每个 Python 程序员入门第一个学的 HTTP 库。

设计哲学很简单：让 HTTP 请求读起来像人话。

importrequests

response = requests.get(
    "https://api.github.com/user",
    params={"page": 1, "per_page": 10},
    headers={"Authorization": "token YOUR_TOKEN"},
    timeout=5
)

print(response.status_code)
print(response.json())

requests.get() 就是“去拿”，params 就是参数，timeout 就是超时。不需要知道什么 coroutine、event loop，对新手极度友好。

优点

1. API 极度简洁。写什么是什么，没有学习成本。
2. 生态丰富。几乎所有 Python 库的底层 HTTP 都用它，插件极多。
3. 文档友好。官方文档像教程，社区答案一搜一大把。
4. 稳定性。十几年了，该踩的坑踩完了，很少出意外。

缺点

说实话，就一个：同步的。

发一个请求，线程就卡在那等服务器响应。并发请求 1000 个接口，它一个一个来，要跑很久。

之前写一个数据采集脚本，用 requests 跑了 40 分钟。换了个方案，10 分钟搞定。差点把头发薅秃。

httpx：新项目首选

httpx 是 2020 年出的，作者之一是 Encode 团队（FastAPI 背后那帮人）。它的目标很明确：做一个同时支持同步和异步的 requests。

importhttpx

# 同步 —— 和 requests 几乎一样
response = httpx.get("https://api.github.com/user")
print(response.json())

# 异步 —— 同样简洁
asyncwithhttpx.AsyncClient() asclient:
    response = awaitclient.get("https://api.github.com/user")
    print(response.json())

API 和 requests 几乎一样，只是多了个 await。熟悉 requests 的人上手成本几乎为零。

httpx 真正厉害的地方

并发请求变得极简单：

importhttpx
importasyncio

asyncdeffetch_all(urls):
    asyncwithhttpx.AsyncClient() asclient:
        tasks = [client.get(url) forurlinurls]
        responses = awaitasyncio.gather(*tasks)
        return [r.json() forrinresponses]

# 1000个URL？5秒跑完
urls = [f"https://api.example.com/item/{i}"foriinrange(1000)]
results = asyncio.run(fetch_all(urls))

性能跟 aiohttp 一个水平，但语法跟 requests 一样干净。

缺点

1. 异步模式下，连接池配置比 aiohttp 少一些。对 99% 的场景够用了。
2. 发布时间比 requests 短，社区踩坑案例少一点。但文档本身质量很高，出问题基本能找到答案。

aiohttp：异步选手里的老江湖

aiohttp 是 asyncio 生态里最早的 HTTP 客户端，2014 年就存在了。它的特点很明确：纯异步，性能拉满。

API 写法跟 requests 不太一样，有一点“异步味”：

importaiohttp
importasyncio

asyncdeffetch(url):
    asyncwithaiohttp.ClientSession() assession:
        asyncwithsession.get(url) asresponse:
            returnawaitresponse.json()

asyncdefmain():
    tasks = [fetch(f"https://api.example.com/item/{i}") foriinrange(1000)]
    results = awaitasyncio.gather(*tasks)

asyncio.run(main())

代码量和 httpx 异步模式差不多，但 aiohttp 更“原生 asyncio”一点。

适用场景

两个明确的用途：

1. 已有 asyncio 项目——如果整个项目都是 async 的（比如用 asyncio 写的爬虫框架），aiohttp 是最顺滑的选择，不引入额外依赖。
2. 写 HTTP 服务器——对，aiohttp 还能写服务端，今天不展开。

缺点

1. API 比 httpx 啰嗦。同样功能的并发请求，httpx 代码更干净。
2. 没有同步模式。想写个简单脚本？不好意思，全局得包 asyncio.run()。
3. 生态不如 requests。有些第三方 SDK 底层只支持 requests，不支持 aiohttp。

选择逻辑

总结了一套决策流程：

你的项目需要异步吗？
    │
    ├─ 不需要 → 用 requests，跑得好就别动
    │
    └─ 需要 → 新项目？→ httpx（同步异步都能跑）
              已有 asyncio 项目？→ aiohttp

我自己的偏好：

• 一次性脚本、工具类 → requests，顺手
• 新启动的 Web 项目、API 客户端 → httpx，面向未来
• 爬虫、数据采集（高并发） → httpx async 或 aiohttp
• FastAPI 项目里发 HTTP 请求 → httpx（FastAPI 官方默认也是 httpx）

几个真实的坑

坑1：不要在 asyncio 项目里混用 requests

# 错误：卡住事件循环
asyncdefget_data():
    data = requests.get(url)  # 这会阻塞整个事件循环
    returndata.json()

在 asyncio 项目里调用同步代码，高并发优势全没了。换 httpx 或 aiohttp。

坑2：httpx 默认不验证 SSL

# 危险！直接跳过证书验证
client = httpx.AsyncClient(verify=False)

生产环境一定要配置证书验证。有内部 HTTPS 的，用 verify="/path/to/ca-bundle.crt" 指定路径。

坑3：aiohttp 不要每次请求都 new Session

# 错误：重复创建 Session，有连接开销
asyncdefbad_fetch(url):
    asyncwithaiohttp.ClientSession() assession:  # 每次都新建
        asyncwithsession.get(url) asresp:
            returnawaitresp.json()

# 正确：全局复用 Session
asyncwithaiohttp.ClientSession() assession:
    tasks = [fetch(session, url) forurlinurls]
    awaitasyncio.gather(*tasks)

高频请求下，Session 重复创建影响明显。

三个库，各有各的场景。

requests 是老将，稳定、皮实；httpx 是新星，一手抓简洁一手抓性能，接班 requests 的势头很明显；aiohttp 在 asyncio 生态里没有对手。

建议：不要三个都装，根据场景选一个用到底就好。

“无他，惟手熟尔”！有需要的用起来！