容错设计需分层：网络请求应配置超时、捕获具体异常并设置降级路径；数据库操作要分离核心与辅助逻辑，非关键写入可用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
<p>def fetch_weather(city):
try:
resp = requests.get(f"<a href="https://www.php.cn/link/acf9e119e44c83b73cb4d489dd7d1e09">https://www.php.cn/link/acf9e119e44c83b73cb4d489dd7d1e09</a>}", 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 事务里，其中一步因唯一键冲突或字段长度超限失败，整个事务回滚，前面成功的操作也白干。这不是数据一致性，是过度耦合。
容错设计要分层：核心业务逻辑（如扣库存）必须强一致；辅助动作（如发通知、记审计日志）应异步化 + 可重试 + 允许丢失。
立即学习“Python免费学习笔记（深入）”；
- 用
try/except包裹非核心 DB 操作，捕获IntegrityError、DataError等具体异常 - 避免在 ORM 的
save()后立刻调用refresh_from_db()—— 若 DB 连接已断，这会二次触发异常 - 对非关键写入（如统计计数器），可用 Redis 的
INCR替代 MySQLUPDATE ... 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
降级开关不能只靠配置文件硬编码
把降级逻辑写死在代码里，比如 if settings.USE_CACHE_ONLY:，上线后想临时切回全量调用，只能改配置、重启服务——这在故障现场就是自断手脚。
真正的降级能力要支持运行时动态控制：
- 用 Redis 的
GET feature:weather:enabled判断是否启用远程调用，值为"0"时自动走缓存 - 开关变更后无需重启，且能按服务实例、用户 ID、请求路径做灰度（例如只对
user_id % 100 == 0的请求开启降级） - 所有降级分支必须打日志，包含开关状态、原始错误原因、fallback 返回内容，否则你永远不知道降级是不是真生效了
容错不是加一堆 try/except，降级也不是写个备用返回值。真正难的是判断哪一层该熔断、哪一层该重试、哪一层该静默失败——这些决策必须基于可观测数据（错误率、延迟 P99、下游 SLA），而不是拍脑袋写的 if 分支。
