降级逻辑是预先设计的平滑退路，通过降低精度、范围或时效性保障服务可用；需明确可降级点与备用变量，用分层try-except实现类型一致、可监控、可追踪的降级，并主动标记、避免雪球效应。
当主业务逻辑抛出异常，系统不能直接报错或中断流程，而应快速、自动地切换到备用方案——这就是“降级逻辑”的核心。它不是兜底的补救，而是预先设计好的、有明确语义的平滑退路。关键在于：降级不是放弃功能，而是降低精度、范围或时效性，同时保持服务可用。
一、降级逻辑的设计前提：明确“可降级点”与“备用变量”
不是所有异常都适合降级，也不是所有环节都能随便换方案。必须在编码前就识别出哪些步骤具备降级条件：
- 数据源可替换：比如主数据库查不到，可切到缓存（Redis）；主向量库超时，可 fallback 到关键词检索
- 模型/服务可分级：调用大模型失败时，改用规则引擎或小模型生成简要回复；高精定位失败，降级为城市级粗略位置
- 计算逻辑可简化：实时风控校验超时，改用离线快照策略；复杂推荐排序失败，返回热门榜单替代
- 返回内容可裁剪：完整详情页加载异常，只渲染标题+摘要+重试按钮；图片生成失败，显示占位图标+文案提示
二、catch 中实现降级的典型结构（以 Python 为例）
降级不是写一堆 if-else 套嵌，而是用清晰的 try-except 分层承接，并让每个 except 块负责一个明确的降级动作：
✅ 推荐写法（带日志、可监控、可追踪）：
try:
result = call_expensive_llm_api(prompt) # 主逻辑
except TimeoutError as e:
logger.warning("LLM timeout, falling back to rule engine", extra={"prompt_len": len(prompt)})
result = apply_rule_based_fallback(prompt) # 一级降级：规则引擎
except (ConnectionError, HTTPStatusError) as e:
logger.error("LLM service unavailable", extra={"status": getattr(e.response, 'status_code', 'N/A')})
result = get_cached_response(prompt) # 二级降级：本地缓存
except Exception as e:
logger.exception("Unexpected LLM error, using default response")
result = {"answer": "当前服务繁忙，请稍后再试。"} # 兜底降级：静态响应
⚠️ 避免写法：在 except 中再嵌套 try-catch、不记录上下文、用空值或 None 直接返回（导致上层 NPE）、降级后不标记状态（无法统计降级率）。
三、关键细节：让降级真正“平滑”
- 降级结果需保持类型一致：主逻辑返回 dict，降级也返回结构兼容的 dict，避免上层代码崩溃
-
主动标记降级发生：在返回体中加
"fallback_used": true或埋点上报，用于后续容量评估和体验优化 - 避免雪球效应：降级逻辑本身不能再触发同级异常（如缓存查询也加超时和 fallback）
- 用户感知可控：前端根据降级标识做轻量提示（如“暂用简化版结果”），而非隐藏一切——透明比“假装正常”更可信
四、真实场景对照示例
电商下单库存校验异常：
- 主逻辑：查分布式锁 + 扣减 Redis 库存 → 抛出
LockAcquireTimeout - 降级路径：跳过分布式锁，走 MySQL 悲观锁重试一次 → 失败则查只读从库库存（允许短暂不一致）→ 最终返回“预计2小时内恢复下单”
金融行情查询异常：
- 主逻辑：调腾讯实时行情 API → 超时或限流
- 降级路径：切至新浪行情（多源配置）→ 再失败则返回本地内存中 30 秒前的快照数据 → 同时异步刷新并标记“数据可能延迟”
