17370845950

容错设计需分层：网络请求应配置超时、捕获具体异常并设置降级路径；数据库操作要分离核心与辅助逻辑，非关键写入可用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

降级开关不能只靠配置文件硬编码

把降级逻辑写死在代码里，比如 if settings.USE_CACHE_ONLY:，上线后想临时切回全量调用，只能改配置、重启服务——这在故障现场就是自断手脚。

真正的降级能力要支持运行时动态控制：

• 用 Redis 的 GET feature:weather:enabled 判断是否启用远程调用，值为 "0" 时自动走缓存
• 开关变更后无需重启，且能按服务实例、用户 ID、请求路径做灰度（例如只对 user_id % 100 == 0 的请求开启降级）
• 所有降级分支必须打日志，包含开关状态、原始错误原因、fallback 返回内容，否则你永远不知道降级是不是真生效了

容错不是加一堆 try/except，降级也不是写个备用返回值。真正难的是判断哪一层该熔断、哪一层该重试、哪一层该静默失败——这些决策必须基于可观测数据（错误率、延迟 P99、下游 SLA），而不是拍脑袋写的 if 分支。