Python 网络异常处理的通用模式

本文深入剖析了Python中使用requests库进行HTTP请求时网络异常处理的完整实践体系，强调必须采用分层捕获策略：优先应对socket.gaierror等底层网络层异常，再处理Timeout、ConnectionError等requests专属异常，最后通过raise_for_status()校验HTTP状态码；同时指出仅依赖单一异常捕获或全局timeout设置的严重缺陷，详解了超时拆分（connect/read）、重试机制（含urllib3 Retry指数退避与Retry-After头支持）、SSL验证、流式响应管理等关键细节，帮助开发者构建真正健壮、可观测、易调试的网络请求容错能力。

捕获 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 状态），最后保数据可用（解析与业务校验）。

重试 + 指数退避的实际写法（不用第三方库）

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）。

今天关于《Python 网络异常处理的通用模式》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！