requests 底层基于 urllib3 而非 urllib，由 urllib3 管理连接池、重试、SSL 验证和 HTTP/1.1 流水线；它不支持 HTTP/2 和异步，重试需手动配置 HTTPAdapter。
requests 底层用的是 urllib3，不是 urllib
requests 本身不直接操作 socket，它把网络请求的细节全交给了 urllib3。这个库负责连接池、重试、SSL 验证、HTTP/1.1 流水线等核心逻辑。你调用 requests.get() 时，实际是 urllib3.PoolManager 在背后管理连接、复用 TCP 连接、自动处理 Connection: keep-alive。
常见误解是 requests 封装了标准库的 urllib.request，其实完全无关——requests 早期确实基于它，但 2013 年起就彻底切换到 urllib3（一个独立维护的第三方库），因为后者支持连接池、更可控的超时、更好的错误分类。
-
requests.Session()对应一个urllib3.PoolManager实例，所以复用 Session 才能真正复用连接池 - 如果你禁用连接池（比如传
pool_connections=0），urllib3会退化为每次新建连接，性能骤降 -
requests.adapters.HTTPAdapter是你和urllib3之间的胶水层，所有自定义行为（如重试策略、池大小）都通过它配置
HTTP/2 和异步不是 requests 的事
requests 是同步阻塞式 HTTP 客户端，不支持 HTTP/2，也不支持 async/await。它发请求时会卡住当前线程，直到响应头收完（或超时）。这意味着：
- 即使服务端支持 HTTP/2，
requests也只走 HTTP/1.1 —— 它压根没实现 HTTP/2 帧解析 - 想并发发 100 个请求？靠
threading或multiprocessing硬扛，不是靠 requests 本身“变快” - 真正的异步替代方案是
aiohttp或httpx（后者 sync/async 双模式，底层用httpcore而非urllib3）
SSL 验证和证书路径由 urllib3 控制，但 requests 提供快捷入口
证书验证逻辑在 urllib3.util.ssl_.create_urllib3_context() 里，它默认加载系统 CA 包（如 certifi），但你可以绕过或替换：
立即学习“Python免费学习笔记（深入）”；
- 设
verify=False会跳过全部 SSL 校验，同时 suppressInsecureRequestWarning - 传路径如
verify="/path/to/cert.pem"，urllib3会用它作为 CA bundle，而非系统默认 - 环境变量
REQUESTS_CA_BUNDLE或CERT_PATH会影响urllib3加载位置，但优先级低于代码中显式传入的verify= - 自签名证书场景下，别只改
verify=False；更安全的做法是导出证书、用verify="mycert.crt"
重试机制必须手动打开，且只对部分状态码生效
requests 默认不重试任何请求。要启用重试，得配 HTTPAdapter 并挂到 Session 上：
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
retry_strategy = Retry(
total=3,
status_forcelist=[429, 500, 502, 503, 504],
allowed_methods=["HEAD", "GET", "OPTIONS"]
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("https://", adapter)
注意几个关键点：
-
total是总尝试次数（含首次），不是“额外重试几次” -
status_forcelist必须显式列出要重试的状态码；400、401、403、404 默认不重试 -
allowed_methods默认不含POST，因为非幂等方法重试有风险；若真要重试 POST，得明确加上 - 重试间隔默认是指数退避，但不会 sleep 主线程——urllib3 在每次重试前会调用
time.sleep()，这点容易被忽略
底层超时（connect / read）和重试是两套独立机制，别以为设了 timeout=(3, 30) 就自动带重试。
