Python 库巡礼 | Requests‌:让HTTP请求回归人类语言

很久很久之前写Python调接口或抓数据，得先跟 urllib2 搏斗一番，拼接参数、手动编解码、处理cookie、抓包看头信息……一套下来，胶水代码比业务逻辑还长。后来 Kenneth Reitz 在博客里留了一句：“HTTP请求本该简单得像说话一样。”然后就有了 requests。

📜 发展历程

🔍 把什么做简单了？

1. 直白的参数传递requests.get(url, params={"q": "test"}) 几乎就是自然语言。不用自己拼 query string，也不用手动设 Content-Type。传表单用 data，传JSON用 json，传文件用 files，库会帮你处理边界情况。

2. Session 与连接复用同一个 Session 实例会自动处理 cookie 持久化和 TCP 连接池。跑批量接口测试、需要登录态保持、或者频繁调用同一域名时，省去大量手动维护状态的代码。很多人不知道 requests.get() 底层每次都会新建连接，遇到性能瓶颈时才想起切到 Session。

3. 智能解码与容错内置编码推断逻辑，自动处理 gzip/br 压缩响应；超时控制 timeout=(connect, read) 明确区分建连和读数据两个阶段，比一刀切的超时更贴近真实网络抖动场景。

4. 流式响应不撑内存加一个 stream=True，配合迭代器逐块读取。下载大文件、处理长轮询或日志推送时，不会一次性把响应体塞进内存。新手常踩的 OOM 坑，往往就是忘了开这个开关。

⚖️ 优点与缺点

优点

• 学习成本极低，新手十分钟能跑通，老手写脚本也懒得换。
• 生态极其成熟，requests-oauthlib、requests-toolbelt 等第三方扩展无缝衔接。
• 错误拦截简洁，response.raise_for_status() 一行搞定非2xx状态码拦截，不用逐层写 if。

缺点

• 纯同步阻塞模型。高并发场景下靠线程池能救急，但上下文切换开销大，不适合万级QPS的微服务或网关层。
• 底层依赖 urllib3，虽然稳定，但现代特性（HTTP/2、原生异步、QUIC）需要额外插件或换用 httpx/aiohttp。
• 默认不限制重试次数。调用不稳定的第三方API时，如果不手动配置 Retry 策略，容易把调用方拖垮或触发限流。

📝 写在最后

在Python的世界里，很多“网红”库火得快，退场也快。requests 能活这么多年，不是因为它技术多前沿，而是它把一件基础小事做到了“不用想”的程度。

如果你在做脚本自动化、数据抓取、内部系统对接，或者只是想快速验证一个 API，用它就够了。别被异步焦虑绑架，同步代码在大多数运维、批处理和定时任务里依然最省心。工具选对，少写一半胶水代码。剩下的时间，留给业务逻辑本身吧~