httpx在高并发下通常比aiohttp更快、内存更省，但性能差异取决于请求类型与连接配置：小文件高频请求需调优aiohttp的TCPConnector（如limit_per_host=0），大文件流式下载httpx更稳定，HTTP/2支持更原生，超时与重试机制也更严谨。
高并发场景下，httpx 通常比 aiohttp 更快、内存更省，但差异取决于请求类型和连接管理方式——不是所有场景都值得切换。
小文件高频请求时，aiohttp 的 TCP 连接器配置直接影响性能
很多人测出 aiohttp 在 100–500 并发 GET 请求中略快，但这依赖于显式调优。默认的 aiohttp.TCPConnector 会限制总连接数（limit=100），而实际压测中若未设 limit_per_host，多个域名请求可能被阻塞在队列里。
- 必须手动设置
limit_per_host=0（不限制每 host 连接数）或按需设值，否则容易卡在连接等待 -
keepalive_timeout建议设为 30–60 秒，避免频繁重建连接 - 若目标服务支持 HTTP/2，
aiohttp需额外安装hypercorn或启用aiostream才能真正用上，否则仍走 HTTP/1.1
大文件或长响应体场景，httpx 的流式处理更稳定
当下载图片、日志、JSONL 流或响应体 >1MB 时，httpx.AsyncClient 的 stream=True 模式天然支持异步迭代，且内部缓冲区管理更保守；而 aiohttp 的 content.iter_chunked() 容易因未及时 await 导致内存堆积。
-
httpx默认启用http2=True（只要服务端支持），复用单连接传输多请求，对 API 聚合类任务吞吐提升明显 -
aiohttp的response.content.readany()是非标准接口，不同版本行为不一致，线上易出RuntimeError: Response content is not fully read - 若需边收边解析（如 SSE），
httpx的aiter_lines()/aiter_bytes()接口语义更清晰，错误边界明确
连接池与超时配置差异常被忽略，导致压测结果失真
两者默认超时策略完全不同：aiohttp 默认无总超时（仅 socket timeout），httpx 默认 5 秒 total timeout。不统一配置就对比性能，等于拿“可能永远卡住”的请求 vs “强制断开”的请求比快慢。
-
aiohttp必须显式传timeout=aiohttp.ClientTimeout(total=5)，否则并发高时大量 pending task 占满 event loop -
httpx.AsyncClient的limits参数（如max_connections=100）控制的是整个 client 实例，而非 per-host，误配会导致连接饥饿 - 两者都依赖底层
asyncio事件循环，但在 macOS 上aiohttp对uvloop兼容性略差，实测延迟抖动比httpx高 10%~15%
迁移成本低不等于零成本：异常类型和重试逻辑要重写
从 aiohttp 切到 httpx 不是改个 import 就完事。最常踩的坑是异常捕获范围变化和重试语义差异。
-
aiohttp.ClientResponseError只覆盖 4xx/5xx 状态码，而httpx.HTTPStatusError需显式调用response.raise_for_status()才抛出 -
httpx的TransportError是基类，包含 DNS、TLS、连接拒绝等，但aiohttp把它们分散在ClientConnectorError/ServerDisconnectedError等多个子类中 - 自定义重试（如指数退避）必须重写：aiohttp 依赖第三方库
aioretry，httpx 内置httpx.AsyncHTTPTransport(retries=3)，但只重试连接类错误，不重试 5xx
真实高并发系统里，连接复用率、DNS 缓存、TLS 握手耗时往往比客户端库本身影响更大。选 httpx 还是 aiohttp，关键看团队是否已有成熟封装——一个调优过的 aiohttp 实例，可能比裸用 httpx 更稳；而一个没设 limits 的 httpx.AsyncClient，上线后可能直接把目标服务打挂。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
