Python 网络请求异常需分层处理：底层连接异常（如 Timeout、DNS 失败）应重试降级；HTTP 协议异常（4xx/5xx）按状态码策略处理；解析异常（JSONDecodeError 等）需校验响应再解析；第三方库异常须单独捕获。
Python 网络请求异常不是一锅炖，得按发生环节分层处理——底层连接、协议响应、业务逻辑各不相同，混着捕获容易掩盖真实问题。
底层连接异常：请求根本发不出去
这类错误发生在 TCP 握手、DNS 解析或 SSL 协商阶段，requests 会抛出 ConnectionError 及其子类，比如：
• Timeout（含 ConnectTimeout / ReadTimeout）
• ConnectionRefusedError（目标 端口 未监听）
• gaierror（DNS 解析失败，如域名不存在或网络不可达）
• SSLError（证书验证失败、协议不匹配等）
处理建议：超时必须显式设置（默认永不超时），DNS 和连接类错误通常需重试 + 降级（如切备用域名或返回缓存），SSL 错误慎用 verify=False，应优先修复证书或配置信任链。
HTTP 协议异常：请求发出去了，但服务端没给“正常”响应
对应 requests.exceptions.HTTPError，本质是响应 状态码 ≥400 且调用了 response.raise_for_status()。常见有：
• 4xx：客户端问题（400 参数错、401 未认证、403 禁止访问、404 资源不存在）
• 5xx：服务端问题（500 内部错误、502 网关错误、503 服务不可用）
处理建议：4xx 一般不重试，需检查参数或权限；5xx 可有限重试（配合指数退避），同时记录 status_code 和 response.text 辅助排查；别依赖 status_code 判断业务成败——比如支付接口返回 200 但 body 中 result=failed 得靠业务字段判断。
解析与使用异常：响应回来了，但程序“读不懂”
这类不在 requests 异常体系内，属于运行时逻辑错误：
• JSONDecodeError（response.json() 解析失败，常见于返回 HTML 错误页或空响应）
• KeyError / TypeError（从 JSON 中取字段时 key 不存在或类型不符）
• UnicodeDecodeError（响应 content 编码 与实际不符，如 GBK 响应被当 UTF-8 解）
处理建议：先检查 response.status_code 和 response.headers.get(‘content-type’)，再决定是否解析；json() 前可用 response.text[:200] 打印调试；关键字段提取用 .get(key, default) 或 try/except 包裹；编码问题优先用 response.apparent_encoding 或手动指定 encoding。
第三方库干扰与并发异常
用 urllib3、httpx 或异步库（aiohttp）时，异常类型不同：
• urllib3 抛出 MaxRetryError、NewConnectionError
• httpx 的 ConnectTimeout、ReadTimeout 属于 HTTPStatusError 之外的独立异常
• aiohttp 中 ClientConnectorError、ServerDisconnectedError 需单独捕获
处理建议：统一异常处理层建议按“连接→响应→解析”三段封装，避免直接 except Exception；异步场景下注意 CancelledError 也要覆盖，否则任务中断可能静默失败。
分层捕获不是为了写更多 try-except，而是让每类错误走对应的恢复路径——连不上就换节点，返回错就查日志，解析崩就补容错。不复杂但容易忽略。
