Python httpx vs requests 在测试中的选择

httpx 在并发场景下通常比 requests 快 2–4 倍，但单次请求未必更快；同步性能相近，httpx 默认支持 http/2；异步测试需用 asyncclient 和 pytest-asyncio；requests 更易 mock 且符合传统测试直觉。

httpx 在测试中真比 requests 快吗？

不一定快，尤其在单次请求、小数据量场景下，httpx 的异步开销反而可能拖慢执行。真正拉开差距的是并发测试：比如用 asyncio.gather() 并发 50 个健康检查请求，httpx.AsyncClient 通常比 requests.session + 线程池快 2–4 倍。

• 同步模式下 httpx.Client 和 requests.Session 性能基本持平，但 httpx 默认启用 HTTP/2（服务端支持时），对多路复用友好
• 异步测试必须用 httpx.AsyncClient，且测试函数得用 async def + pytest-asyncio 插件，否则直接报 RuntimeWarning: coroutine 'AsyncClient.get' was never awaited
• 别在 pytest 的 setup_method 里初始化 AsyncClient——它不是线程安全的，更不能跨 async Event loop 复用

requests.Session 为什么在单元测试里更省心？

因为它的生命周期和行为完全符合传统测试直觉：实例化 → 发请求 → 关闭，不依赖 event loop，也不要求整个测试链路异步化。

• requests.Session 可以轻松 patch：用 unittest.mock.patch('requests.Session.request') 拦截所有请求，而 httpx 的 mock 需要额外装 httpx_mock 或手动构造 httpx.MockTransport
• HTTP header、cookie、auth 等配置方式几乎一致，迁移成本低；但 requests 对 Unicode URL 编码更宽松，httpx 会严格报 InvalidURL: URL has an invalid label
• 若测试涉及重定向链或 stream=True 场景，requests 的 Response.history 和 iter_lines() 接口更稳定，httpx 的 response.next_request 和流式读取需额外处理异常关闭

mock httpx 异步请求容易卡在哪？

卡在 transport 层没配对，或者忘记 await —— 这是最常见的两个断点。

• 用 httpx_mock 时，必须确保 mock 是在同一个 AsyncClient 实例上注册的，且调用前没调用过 client.aclose()
• 手动 mock transport 要返回 httpx.Response 实例，不能只 return dict 或 tuple，否则触发 TypeError: 'dict' Object is not callable
• pytest 中如果混用 @pytest.mark.asyncio 和普通测试函数，会静默跳过 await，导致断言永远跑在 None 上，建议统一用 async def test_xxx() + 显式 await

什么时候该强行切到 httpx？

当你的被测服务本身是 ASGI（如 fastapi、Starlette），且测试逻辑天然需要并发压测、websocket 测试、或 HTTP/2 特性验证时，httpx 就不是“可选”，而是事实标准。

立即学习“Python免费学习笔记（深入）”；

• FastAPI 官方文档示例全用 httpx.AsyncClient，因为它的测试客户端 TestClient 底层就基于 httpx
• 要测 server-sent events（SSE）或长连接流响应，httpx 的 aiter_lines() 和 aread() 支持比 requests 的 iter_lines() 更贴近真实运行时行为
• 注意 httpx 默认禁用 ssl 验证（verify=False）只在 dev 模式生效，CI 环境里如果用了自签名证书，必须显式传 verify="/path/to/cert.pem"，否则报 SSLError: certificate verify failed

实际用哪个，取决于你测的是什么、怎么跑、以及团队对异步心智模型的熟悉程度。httpx 不是 requests 的升级版，它是另一套协作契约——接受它，就得接受它的生命周期规则和错误提示风格。