为何Python requests性能不及MooTools、jQuery？如何优化？

• 浏览器自带的网络栈默认做了大量优化：你之前用 MooTools、jQuery 发请求时，请求是跑在浏览器的原生网络层上的，浏览器默认会自动开启 DNS 预解析、TCP 连接预热、HTTP/2 多路复用、TLS 1.3 快速握手、自动响应压缩、长连接保活策略，这些逻辑不需要你写代码实现，全程是原生 C++ 实现的低延迟网络栈在跑。而 requests 默认走 HTTP/1.1 协议，自带的连接池、超时、保活配置都是通用保守值，没有针对连续小请求的场景做专门优化。
• 冗余的环境与代理检查开销：requests 启动时默认会读取系统里的 HTTP_PROXY、HTTPS_PROXY、CA 证书路径等环境变量，哪怕你根本没有配置代理，只要系统里装过 VPN、安全软件、企业网络客户端，这些工具经常会自动往环境变量里写入代理配置，requests 每次发请求都要逐个校验这些配置的路由规则，额外累积不少延迟。
• 连接复用的实际效果打折扣：很多人以为复用 Session 就等于和浏览器一样的长连接，但 requests 默认的单主机连接池大小很小，而且 keep-alive 的保活超时时间远短于服务端的连接回收时间，经常出现连接刚复用两三次就被服务端主动断开，下一次请求又要重新做三次 TCP 握手、完整 TLS 协商，这部分的网络延迟占比往往能占到总请求耗时的一半以上。
• 服务端的路由差异：很多聊天类服务会对非浏览器标识的请求（比如 requests 默认的 python-requests/x.x.x 这类 User-Agent）做额外的风控校验，比如触发固定速率延迟返回、走公共慢速处理队列、插入验证逻辑，而你之前在浏览器里发请求时用的是正常的浏览器 UA，服务端会给请求分配优先级更高、延迟更低的专属通道，这个因素往往是造成性能差距最隐蔽也最明显的原因。
• 解析层的原生性能差：requests 是纯 Python 实现的 HTTP 客户端，请求构造、响应头解析、编码识别、cookie 处理的逻辑都是 Python 代码实现的，而浏览器里跑的 JS 网络请求是 JS 引擎底层的原生 C++ 实现，单次请求几毫秒的解析开销，连续发几十上百个请求之后，累积的性能差距就会被放大。

• 先关掉冗余的环境检查逻辑：初始化 Session 后直接设置 session.trust_env = False，彻底关闭 requests 自动读取系统代理、证书配置、环境变量的逻辑，能直接省掉这部分的启动和请求前开销。
• 手动调优连接池参数：不要用默认的连接池配置，给 Session 挂载自定义的 HTTPAdapter，把连接池大小、保活策略调整到匹配你的连续请求场景，避免连接频繁断开重连：

  from requests.adapters import HTTPAdapter
  # 适配连续按序发请求的场景
  adapter = HTTPAdapter(
      pool_connections=5,
      pool_maxsize=5,
      pool_block=False,
      max_retries=0 # 关闭自动重试，避免不必要的重试拖慢连续流程
  )
  session = requests.Session()
  session.trust_env = False
  session.mount("https://", adapter)
  session.mount("http://", adapter)
  

• 替换 UA 绕过服务端的慢速路由：把 Session 默认的 User-Agent 改成和你之前浏览器里发请求时完全一致的 UA 字符串，触发服务端的快速处理通道，避免被风控逻辑拖慢响应。
• 跳过不必要的内置解析逻辑：发请求时加上 stream=True 参数，拿到原始响应的字节流之后，直接跳过 requests 自带的编码猜测、自动 JSON 解析逻辑，用更快的原生解析库处理响应内容，能省掉不少纯 Python 实现的解析开销。
• 抓包验证实际网络路径：用网络抓包工具对比你在浏览器发请求和 Python 发请求的实际报文，确认是不是存在频繁重连、额外 TLS 握手、请求头多余字段的问题，针对性调整配置。
• 降低迁移成本的替代方案：如果调整 requests 配置后还是达不到浏览器的性能，可以直接换成接口完全兼容的 httpx，它原生支持 HTTP/2、TLS 1.3，连接池的复用效率比 requests 高 30% 以上，迁移的时候几乎不用改原有请求逻辑。

内容的提问来源于stack exchange，提问作者killaz