HTTP状态码需精细化处理：2xx需校验业务码，4xx按类型触发鉴权/退避，5xx做重试或降级；避免直接raise_for_status，应显式判断并封装结构化响应。
Python调用HTTP接口时，光靠try...except捕获网络异常远远不够——真正影响业务逻辑的，往往是返回的HTTP状态码。2xx看似成功，但200里可能含错误业务码；4xx/5xx也不只是“失败”两个字能概括，比如401要刷新token，429得退避重试，503可能需切换备用接口。
常见HTTP状态码含义与应对策略
状态码是服务端对请求的语义反馈，不是简单分“成功/失败”。关键要区分三类：
-
2xx（成功类）：如
200 OK表示HTTP层成功，但响应体中{"code": 40001, "msg": "用户不存在"}仍是业务失败；201 Created常用于POST后资源创建成功，需解析Location头获取新资源地址 -
4xx（客户端错误）：如
400 Bad Request多因参数校验失败，应检查请求数据格式；401 Unauthorized说明认证失效，需重新登录或刷新access_token；429 Too Many Requests代表被限流，建议加入指数退避（如首次等1s，二次等2s，三次等4s） -
5xx（服务端错误）：如
500 Internal Server Error属未知服务异常，适合记录日志并告警；503 Service Unavailable常因服务过载或维护，可尝试降级到缓存或备用接口；504 Gateway Timeout说明上游响应超时，需检查依赖链路
requests库中正确解析状态码的写法
别直接用r.raise_for_status()一棍子打死——它会把所有非2xx都抛出HTTPError，导致无法区分4xx和5xx处理逻辑。推荐显式判断：
import requestsr = requests.post(url, json=payload, timeout=10) if r.status_code == 200: try: data = r.json() if data.get("code") != 0: # 假设0为业务成功 handle_business_error(data) else: process_success(data) except ValueError: handle_json_parse_error(r.text) elif r.status_code in (401, 403): refresh_auth_token() retry_request() elif r.status_code == 429: wait_and_retry(r.headers.get("Retry-After", 1)) elif r.status_code >= 500: log_server_error(r) fallback_to_backup_service() else: log_unexpected_status(r.status_code, r.text)
封装健壮的请求函数：自动分类处理
把状态码分支逻辑收进统一方法，避免每个接口重复写判断：
立即学习“Python免费学习笔记（深入）”；
- 定义状态码分组：如
CLIENT_ERRORS = {400, 401, 403, 404, 429}、SERVER_ERRORS = {500, 502, 503, 504} - 对4xx做精细化处理：
401/403触发鉴权流程，429自动加入退避队列，其他4xx直接返回原始错误供上层决策 - 对5xx默认重试（最多2次），但排除
501 Not Implemented等不可重试状态码 - 始终返回结构化结果：
{"success": bool, "data": ..., "error": {...}, "status_code": int}，上层无需关心HTTP细节
调试与监控建议
线上问题常卡在“明明返回200却没数据”，根源往往在状态码被忽略：
- 开发期强制打印
r.status_code和r.headers.get("Content-Type")，确认是否真返回JSON而非HTML错误页 - 在日志中固定字段记录
http_status、response_time、upstream_service，便于ELK聚合分析高频错误码 - 对
429和503设置独立监控告警，这类状态码上升通常预示限流策略变更或下游服务雪崩 - 用
httpx替代requests时注意：其raise_for_status()行为一致，但异步模式下需用async with管理连接
