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
