requests 的性能瓶颈源于 Python 的 GIL 和同步 I/O 模型，导致高并发下串行阻塞、连接复用不足、无 HTTP/2 支持、SSL/DNS 未优化，且缺乏异步能力与细粒度控制；替代方案依需求选 httpx、aiohttp 或 urllib3。
requests 的瓶颈主要不在它自身，而在于 Python 的 GIL 和同步 I/O 模型——它本质是阻塞的，单线程下并发请求会串行等待，无法充分利用现代 CPU 和网络带宽。
阻塞式 I/O 导致高并发场景性能骤降
每个 requests 调用（如 requests.get()）都会阻塞当前线程，直到响应返回。100 个请求串行发出，总耗时 ≈ 所有响应时间之和；即使网络延迟低，也难以并行化。
- 没有内置异步支持，不能像 Node.js 或 Go 那样轻量级并发
- 用多线程勉强缓解（
ThreadPoolExecutor），但受 GIL 限制，CPU 密集型任务不受益，且线程开销大（内存、上下文切换） - 用多进程绕过 GIL，但进程启动/通信成本高，不适合 I/O 密集型高频请求
连接复用有限，HTTP/2 支持缺失
requests 基于 urllib3，支持 HTTP/1.1 的 keep-alive 和连接池，但默认配置保守（如 pool_maxsize=10），高并发时容易出现 Max retries exceeded 或连接等待。
- 不原生支持 HTTP/2（无头部压缩、多路复用），无法降低延迟、提升吞吐
- 连接池需手动调优（如增大
maxsize、设置block=True），否则易成为瓶颈 - SSL 握手、DNS 解析等环节未做异步或缓存优化，默认每次请求都可能重复执行
缺乏流式响应与细粒度控制
虽支持 stream=True，但底层仍是同步读取，无法真正边收边处理大响应体；超时、重试、鉴权等逻辑耦合在高层 API 中，不易定制或观测。
立即学习“Python免费学习笔记（深入）”；
- 超时分
connect和read，但无法设置“总超时”或按阶段回调 - 重试策略固定（urllib3 的
Retry），难适配服务端返回码、网络抖动等复杂场景 - 无请求生命周期钩子（如发送前、收到 header 后、body 流式接收中），调试和监控不便
替代方案更适配不同需求
不是 requests 不好，而是定位不同：它追求简洁、可靠、人类可读，而非极致性能或灵活性。
- 需要高并发 I/O → 用
httpx（支持 sync/async，HTTP/2，API 兼容 requests） - 纯异步场景 → 用
aiohttp（原生 async/await，连接池精细可控） - 极简嵌入或资源受限 → 用
urllib3直接操作（跳过 requests 封装开销） - 需要强监控/代理/证书管理 → 用
httpx或封装 requests +requests-toolbelt
