Python健壮程序设计方法_容错与降级处理方案【教程】_技术教程

容错设计需分层：网络请求应配置超时、捕获具体异常并设置降级路径；数据库操作要分离核心与辅助逻辑，非关键写入可用Redis；JSON解析须防御性解包并校验类型；降级开关需支持运行时动态控制与灰度。

遇到网络请求失败时，别直接抛异常

程序在调用 requests.get() 或 urllib.request.urlopen() 时，一旦网络抖动、目标服务超时或返回非 2xx 状态码，就崩掉——这不是健壮，是裸奔。

关键不是“要不要重试”，而是“重试几次、等多久、失败后怎么兜底”。比如对第三方天气 API 的调用，可以接受 5 秒内返回缓存值，但不能卡住主流程：

用 requests.Session() 配置全局超时：timeout=(3, 7)（连接 3 秒，读取 7 秒）
捕获具体异常：requests.exceptions.Timeout、requests.exceptions.ConnectionError，而不是笼统的 Exception
降级路径必须有明确 fallback：返回本地 JSON 文件里的默认天气、或上一次成功结果（需加时间戳判断是否过期）

import requests
from datetime import datetime
def fetch_weather(city):
try:
resp = requests.get(f"https://www./link/acf9e119e44c83b73cb4d489dd7d1e09}", timeout=(3, 7))
resp.raise_for_status()
return resp.json()
except requests.exceptions.Timeout:
return get_cached_weather(city)  # 自定义缓存读取函数
except requests.exceptions.ConnectionError:
return {"status": "offline", "data": None}
except requests.exceptions.HTTPError:
return {"status": "invalid_response", "data": None}

数据库操作失败不能让整个事务回滚成空转

写入日志、更新用户积分、扣减库存——这三步如果放在一个 DB 事务里，其中一步因唯一键冲突或字段长度超限失败，整个事务回滚，前面成功的操作也白干。这不是数据一致性，是过度耦合。

容错设计要分层：核心业务逻辑（如扣库存）必须强一致；辅助动作（如发通知、记审计日志）应异步化 + 可重试 + 允许丢失。

用 try/except 包裹非核心 DB 操作，捕获 IntegrityError、DataError 等具体异常
避免在 ORM 的 save() 后立刻调用 refresh_from_db() —— 若 DB 连接已断，这会二次触发异常
对非关键写入（如统计计数器），可用 Redis 的 INCR 替代 MySQL UPDATE ... SET count = count + 1，天然支持高并发与容忍短暂不可用

JSON 解析失败时，别假设结构永远不变

调用外部接口返回 JSON，用 json.loads() 解析后直接访问 data["user"]["profile"]["avatar_url"]，只要任意一层 key 缺失或类型不对，就报 KeyError 或 TypeError。线上环境里，上游改个字段名、加个嵌套层级、甚至临时返回空字符串，都可能让服务雪崩。

安全做法是“防御性解包”，而不是“信任式取值”：

用 dict.get() 链式调用，配合默认值：data.get("user", {}).get("profile", {}).get("avatar_url", "")
对关键字段做类型校验：isinstance(raw_id, int) 而不是直接传给 User.objects.get(id=raw_id)
考虑引入 pydantic 定义响应模型，用 model_validate() 做结构+类型双校验，失败时抛出可分类的 ValidationError