requests 请求异常需分层捕获：先处理 socket.gaierror 等网络层异常，再捕获 requests.exceptions.Timeout、ConnectionError 等，最后用 raise_for_status() 处理 4xx/5xx 状态码。
捕获 requests 请求失败的常见异常类型
requests 库发起 HTTP 请求时，不会把所有错误都抛成 requests.exceptions.RequestException 的子类，实际中容易漏掉底层网络层异常。比如 DNS 解析失败会抛 socket.gaierror，连接超时是 requests.exceptions.Timeout，而服务端返回 4xx/5xx 状态码却不会触发异常——除非你显式调用 response.raise_for_status()。
-
requests.exceptions.Timeout：请求在指定timeout内未收到响应（含连接和读取两阶段） -
requests.exceptions.ConnectionError：DNS 失败、拒绝连接、SSL 握手失败等底层连接问题 -
requests.exceptions.TooManyRedirects：重定向超过默认 30 次限制 -
requests.exceptions.RequestException：所有 requests 异常的基类，可兜底但不推荐单独捕获它来掩盖具体问题
示例中不要只写 except Exception:，否则会吞掉 KeyboardInterrupt 或 SystemExit，干扰调试和脚本退出逻辑。
为什么不能只靠 try/except 包裹 response.raise_for_status()
很多初学者以为只要捕获 raise_for_status() 抛出的异常就够了，但这是错觉。这个方法只检查 HTTP 状态码是否为 4xx/5xx，完全不管网络是否通、证书是否有效、响应体是否为空或 JSON 是否合法。
- 如果服务器返回 200 但响应体是空字符串，
response.json()会抛json.JSONDecodeError - 如果用了
verify=False绕过 SSL 验证，可能遇到requests.exceptions.SSLError（尤其在旧系统 OpenSSL 版本下） - 如果设置了
stream=True，但没消费完响应流就退出，可能引发连接复用异常或资源泄漏
真正健壮的处理要分层：先保连接通（网络异常），再保状态可用（HTTP 状态），最后保数据可用（解析与业务校验）。
立即学习“Python免费学习笔记（深入）”；
重试 + 指数退避的实际写法（不用第三方库）
requests 本身不带重试机制，但标准库 urllib3 提供了 Retry 类，可直接注入到 Session 中。手动实现简单重试时，注意别用固定间隔（如 sleep(1)），否则可能触发服务端限流或雪崩。
- 使用
urllib3.util.retry.Retry可精确控制哪些状态码/异常触发重试（比如只重试ConnectionError和 502/503/504） -
backoff_factor参数决定指数退避基数：第一次重试延迟backoff_factor * (2^(retry_number - 1))秒 - 注意设置
respect_retry_after_header=True，让客户端遵守服务端返回的Retry-After头
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
session = requests.Session()
retry_strategy = Retry(
total=3,
status_forcelist=(502, 503, 504),
backoff_factor=1,
allowed_methods=frozenset(['HEAD', 'GET', 'OPTIONS', 'POST']),
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)超时设置必须拆成 connect 和 read 两部分
只设一个全局 timeout=5 看似简洁，但实际掩盖了两类完全不同的问题：
-
connect超时：TCP 连接建立耗时过长（DNS 查询、SYN 重传、防火墙拦截等） -
read超时：连接已建好，但服务端迟迟不发响应或发送中断（如慢查询、挂起）
生产环境建议显式分开：
-
connect超时设短（如 3–5 秒），因为连接失败通常意味着服务不可达或网络配置错误 -
read超时可稍长（如 10–30 秒），尤其对上传文件或导出报表类接口
如果共用一个值，在高延迟网络下可能误判“连接失败”，而在服务端卡死时又无法及时中断。
真正难处理的是那些既不超时也不返回的“半开连接”——这时候需要依赖操作系统级别的 TCP keepalive，Python 层面无法直接控制，得靠 socket.setsockopt 或改用异步方案（如 aiohttp）。
