requests.get()默认不因404/500报错，需手动检查status_code或调用raise_for_status()；推荐先判状态码再解析json，并对4xx/5xx分类处理，结合retry策略重试5xx，避免盲目重试导致雪崩。
requests.get() 遇到 404/500 时默认不报错，得手动检查
Python 的 requests 库默认把 HTTP 非 200 响应当作“合法响应”处理，response.status_code 是 404 或 502 时，response.raise_for_status() 才会抛出 requests.exceptions.HTTPError。很多开发者直接用 response.json()，结果在 404 返回空体或 HTML 错误页时触发 JSONDecodeError，而不是预期的业务异常。
推荐做法是：始终检查状态码再决定后续逻辑，尤其微服务间调用需明确区分「客户端错」「服务端错」「重试型错误」：
- 4xx 类（如
400、401、404）通常不重试，应转为业务异常或降级处理 - 5xx 类（如
500、502、503）可结合指数退避重试，但要限制次数（比如最多 2 次） - 对
response.text做json.loads()前，先确认response.headers.get("content-type", "").startswith("application/json")
用 requests.Session() + mount 自定义 HTTPAdapter 控制重试行为
微服务调用失败后盲目重试可能雪崩，但完全不重试又影响可用性。靠手写 try/except 套循环太糙，urllib3 内置的重试机制更可靠，且能精细控制哪些状态码触发重试。
关键点在于：默认 Retry 不重试 4xx（除 413、429），但你要重试 502、503、504，就得显式传参：
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
session = requests.Session()
retry_strategy = Retry(
total=2,
status_forcelist=(502, 503, 504),
allowed_methods=["GET", "HEAD", "OPTIONS"],
backoff_factor=0.3
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)
注意：allowed_methods 默认不含 POST，因为非幂等请求重试有风险；如果真要重试 POST，必须确保服务端支持幂等性（例如通过 Idempotency-Key 头）。
统一包装 API 调用函数，避免每个地方重复判断状态码
在多个服务间频繁调用时，散落在各处的状态码判断会导致逻辑不一致、漏处理 429 或 401。建议封装一个 call_service() 函数，集中处理通用策略：
- 自动解析 JSON，对非 JSON 响应记录警告并返回
{"error": "non-json-response", "raw": response.text[:200]} - 将
401映射为AuthError，429映射为RateLimitError，方便上层except - 对
5xx记录service_name、endpoint、status_code到结构化日志，用于告警 - 超时统一设为
timeout=(3.0, 7.0)（连接 3 秒，读取 7 秒），避免单个慢请求拖垮整个请求链
示例片段：
def call_service(url, method="GET", **kwargs):
try:
resp = session.request(method, url, timeout=(3.0, 7.0), **kwargs)
if resp.status_code == 401:
raise AuthError(f"Unauthorized calling {url}")
if resp.status_code == 429:
raise RateLimitError(f"Rate limited on {url}")
if 400
<h3>别忽略 Content-Type 和空响应体，否则 .json() 会炸</h3>
<p>微服务返回非 200 状态码时，有些框架（如 Flask 默认错误处理器）返回的是 HTML 错误页，有些返回纯文本（如 Nginx 的 502），还有些直接空响应（如某些 gRPC-gateway 实现）。此时调用 <code>response.json()</code> 必然抛 <code>JSONDecodeError</code>，而这个异常和网络错误混在一起，很难定位真实问题。</p>
<p>安全做法是：只在确认响应体存在且类型为 JSON 时才解析：</p>
- 用
response.content判断是否为空（if not resp.content: return {}） - 用
"application/json" in resp.headers.get("content-type", "")做粗略判断，比resp.json()更早失败 - 捕获
JSONDecodeError并记录原始resp.text前 200 字符，这对排查网关透传错误特别有用 - 不要依赖
response.ok—— 它只判断status_code ，而 400–499 里有很多需要 JSON 解析的业务错误（如 <code>400 {"code":"INVALID_PARAM"}）
最常被忽略的是：HTTP/2 或某些代理会在 502 时直接截断响应头，导致 content-type 缺失，这时候得 fallback 到尝试解析再捕获异常。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
