encode开源的Python HTTP客户端，15k Star背后是requests的全面进化

写Python的人几乎没有不知道requests库的。Kenneth Reitz在2011年发布的这个库，凭借一句requests.get(url)就成了Python HTTP请求的事实标准。但requests有一个硬伤：只支持同步调用，HTTP协议也停留在1.1版本。

当FastAPI、Starlette这类异步框架在2019年后快速普及，大量开发者在应用层用async/await写业务逻辑，到了网络请求层却只能用同步的requests时，异步框架的优势就被架空了一半。HTTPX正是这个时间点出现的。

项目由encode团队开发维护。这个团队同时是Django REST Framework、Starlette和uvicorn的维护者，在Python Web领域的积累横跨同步和异步两代技术栈。截至目前GitHub上15,276个Star，超过150位贡献者参与。

API跟requests几乎一样，迁移成本很低

HTTPX的设计思路很直接：保留requests用户熟悉的调用方式，然后补齐异步和HTTP/2。同步代码写出来跟requests几乎一样：

import httpx
r = httpx.get('https://www.example.org/')
r.status_code  # 200
r.json()       # 解析JSON响应

切换到异步模式时，把Client换成AsyncClient，方法调用前加await即可：

async with httpx.AsyncClient() as client:
    r = await client.get('https://www.example.org/')

同步和异步各对应一套独立的客户端类，界限明确。同一个项目里两种可以共存，但不能在一段代码里混用。这个设计避免了异步传染效应导致调试困难的问题。

三个requests无法提供的能力

第一，HTTP/2原生支持。 requests底层走urllib3，协议固定在HTTP/1.1。HTTPX通过httpcore做底层传输，支持HTTP/2的多路复用和头部压缩。安装时加上pip install httpx[http2]，之后请求自动协商协议版本，不需要改任何调用代码。

第二，内置命令行客户端。 装完pip install httpx[cli]，终终端里就能直接发HTTP请求。输出自带JSON语法高亮和格式化，比curl的原始文本输出更适合调试和排查。

第三，强制的默认超时。 requests过去被诟病最集中的问题就是默认不设超时，某个请求网络异常时可能无限挂起，在线上的影响尤其隐蔽。HTTPX给所有请求都配置了默认超时，从库的层面规避了这类问题。

工程质量的几个细节

HTTPX的测试覆盖率达到100%，所有公开API都有类型注解。对于使用PyCharm或VSCode的开发者，这意味着自动补全准确，静态类型检查不会在HTTP调用层报一堆警告。

另外HTTPX可以直接向WSGI和ASGI应用实例发请求。写测试的时候不用先启动一个Web服务进程，直接把FastAPI或Django的app对象传给HTTPX，就能完成完整的端到端接口测试。这个特性对测试效率提升明显，也是requests做不到的。

依赖方面，底层核心是httpcore，一个专门为HTTPX设计的传输实现，比urllib3更轻量。可选依赖包括h2用于HTTP/2，socksio用于SOCKS代理，rich和click用于CLI功能。

适合什么人用

如果你在FastAPI或Starlette项目中做微服务间调用，HTTPX基本是异步HTTP客户端的首选。相比aiohttp，HTTPX的主要优势是API跟requests一致，团队里不用维护两套风格的HTTP调用代码。

如果你目前用requests且没有异步需求，可以继续用。但新项目建议直接上HTTPX，将来需要并发请求或HTTP/2时不用重构网络层。

目前的一个明确限制是不支持HTTPS代理，只支持HTTP代理。如果你的环境要求HTTPS代理，暂时还得用requests或aiohttp。此外httpcore的生态成熟度还比不上urllib3，好在encode团队的发布频率和问题响应速度都不错，项目活跃度有保障。

HTTPX使用BSD协议开源，商业使用没有障碍。

de团队的发布频率和问题响应速度都不错，项目活跃度有保障。

HTTPX使用BSD协议开源，商业使用没有障碍。